site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On May 7, 2010, at 2:59 AM, Alastair Houghton wrote: —Jens _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... Why do that? My understanding is that jemalloc's primary advantage is massive scalability for heavily threaded code. Firefox isn't *that* heavily threaded, right? In any event, the system allocator on Mac OS X has always been pretty good, and it looks like the Snow Leopard version is already designed with per-processor "magazines" for small allocations. Safari has long used a custom allocator (tcmalloc) for performance reasons. It makes a significant difference on standard browser benchmarks, I'm told, although I heard that before 10.6 came out. Chrome uses tcmalloc on Windows and Linux, and probably will eventually on Mac too. Neither of these goes as far as overriding malloc itself. Instead they define their own allocator functions and then use those instead of calling malloc directly. (Simply overriding ::operator new() gets you a lot of the way there, for a C++ app.) In the case of JavaScript (or other GC'd languages) you get the biggest speed boost from not using a normal allocator at all. The usage patterns of a GC system are very different because freeing blocks happens rarely and in huge batches. A typical GC allocator will allocate space by simply bumping a global pointer, and trigger a minor collection when the pointer hits the end of the space. This is one of the things that makes V8 fast. This email sent to site_archiver@lists.apple.com