May 2010 - Darwin-dev - lists.apple.com

Re: jemalloc to replace default allocator
by Jean-Daniel Dupas 08 May '10

08 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Le 7 mai 2010 à 22:30, Jens Alfke a écrit : > > On May 7, 2010, at 2:59 AM, Alastair Houghton wrote: > >> 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. I agree for Javascript. The OP didn't tell us it was for Javascript in its first mail. As suggested sooner, if the bottleneck is in the Javascript library, it makes sense to use a custom allocator for this specific part. But I would not recommend replacing the default malloc for the whole application unless it proves useful. -- Jean-Daniel _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: jemalloc to replace default allocator
by Jens Alfke 07 May '10

07 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On May 7, 2010, at 2:19 PM, Alastair Houghton wrote: —Jens _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… As I hinted, if it were *my* application, I'd be looking at why it's calling free() so much. If that's happening, perhaps it's allocating and releasing too much and maybe caching and re-using objects might help (for instance). I believe Joel said it's primarily JavaScript objects, and there's not much the app can do about that. As a scripting language, JS creates objects promiscuously, and the collector has to free them all. (Collectors that do their own allocation can avoid most of the free overhead, but not ones that are layered on malloc.) This email sent to site_archiver(a)lists.apple.com

1 0

Re: jemalloc to replace default allocator
by Alastair Houghton 07 May '10

07 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 7 May 2010, at 21:30, Jens Alfke wrote: > 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. My impression is that the OP was actually talking about constructing a new default malloc() zone but using jemalloc's routines rather than the historic OS X implementation, which is what's making matters difficult. As I hinted, if it were *my* application, I'd be looking at why it's calling free() so much. If that's happening, perhaps it's allocating and releasing too much and maybe caching and re-using objects might help (for instance). Kind regards, Alastair. -- http://alastairs-place.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: jemalloc to replace default allocator
by Jens Alfke 07 May '10

07 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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(a)lists.apple.com

1 0

Absolute Addressing and asm
by Duane Murphy 07 May '10

07 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 We are adding some assembly optimizations to our code. We are running into a problem with text relocations. I'm looking for suggestions for articles or information on how to go about fixing this problem. The linker returns: ld: absolute addressing (perhaps -mdynamic_no_pic) used in (some function) from (path to some library) not allowed in slidable image. Use '--read_only_relocs suppress' to enable text relocs The function and file identified in the library are part of our assembly optimizations. This happens when linking a library built with the assembly code into a framework (aka dylib). Looking at the code, the problem stems from access to an external table. The table is compiled in a .c file. The assembler has no (automatic) way of constructing a relative address to that table. This apparently leaves the linker to work out what the address is, which leaves the assembly in a state where it wants an absolute address. (Yes, some of this is guessing, which is why I am asking. :-) I am also working towards using this same code in a kext which, I expect, will have similar issues. Can anyone recommend reading or suggestions for how to resolve this situation? Thank you for your suggestions, ...Duane -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.10.0 (Build 500) Charset: US-ASCII wsBVAwUBS+R260rg9acQ4r2CAQi9TAgA3UvbWNdSYHjWNmPw7UE7gO1cizwUtx3L XxqTVvkLtlT+qbBUDdxpTCesiffKFyKv2QNrqkh68/nBZHRANsqbjh/JD5d0m4nl 0YyMIYAqZVj6QKEpBJWLEXdOvxHqjy0zHkWIIT9F3y1q2jIJCkk3mXdFNjYlwE1t LIHm1wTjxY84ewDrDxuScOoLuPIFsfbS3s0zsqNPkXLi8isTG3mWjXGkuZU6Khig hylw2Nxq2IIM1lyYZ2QV+1l8iK2g6RhQy5nP5c+kXWb6U7GZz6k7ozb+Et8/Uau3 FwqOcisY3hAPRqBjKgRJnoZKCadQP9fBGdQ/FMXZF+JeZWmF+MOj7Q== =+5yC -----END PGP SIGNATURE----- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: jemalloc to replace default allocator
by David Leimbach 07 May '10

07 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=a8G4bhw+vjhezKAM3Xz87gIH/zPc3Gzg1c/3imk96gg=; b=SL6mUzttt2rJL0DwaHDrDrrpFZLQQOzjKGV6qzuSfxQ02c6RLtJZgQShByHQVATi06 N3x02rft5X4LmG4RSwd8Grlsuda67+ug8glC8cAqn3fa9R9KB5kNRC1OsBm0FsyGEtvg jbeivhqlXrP31+5rJi4jg67JjaMmHf1AofnQo= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tPR+CMBEC4OjPEEgzok0luVybnHdJ/JyigZG2/nrqKNbBlgUDSnBMfHHIxieaI3L9x mgplSGq50BziAfjcwEx+cScoHFNqcddWSGlBUKdwZObCLfR323yVfVzGdZCoAVWcszMF CHLrzoM2UPUM35taA9s2sSyfC/dRLUpWAfDzQ= _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: jemalloc to replace default allocator
by Joel Reymont 07 May '10

07 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=cplPbF79IVVPxazLpzQBRIq3y9NMDCVdV62lYUHqr80=; b=Rl7t9XUaX43bB5lxNEEY6DNoPE7L9//GLFwccU5SQTNorQcR7Q3MNxCWEbcpCirOLn Vhy/T43b0KeWEhYBdSLbW4aSjF/xyG1xyXmtzcz2P14bEZmh+me9hWWGsn7BrLxI1PxG MwJdN1Zcx+FPf4nURpJHQyGVKPL6zipMg3OpQ= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=ZDQaZ7V5iNX+aiEXBins3rwyti6NKtaXdzpXr18MSirPoKHPqfAEy0+5MBIbbD8juY PMslnP4dS2q7aS7hK9jUwV55SOb8GznxyosInKGoIw80X7Rb1Q7SM9dpv3TSTkZVuduY 3H9oVA2p4Y8tm5OEt2HZKB1qc2PH0ODkeewuU= On May 7, 2010, at 11:23 AM, Jean-Daniel Dupas wrote: > But I agree with Alastair, I doubt you get any performance improvement using a custom allocator. The system allocator is pretty good for general purpose applications (like Firefox) What about Safari and Chrome using tcmalloc instead of the default allocator? Here's a thread from the Chromium mailing list: http://groups.google.com/group/chromium-dev/browse_thread/thread/60f5b665c9… "From a performance perspective, it may be critical to use tcmalloc to match safari performance." --- http://twitter.com/wagerlabs _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: jemalloc to replace default allocator
by Alastair Houghton 07 May '10

07 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=coriolis-systems.com; h= subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=aug07; bh=+7px/yGOjPObThGtiPji9odf/AE=; b=LxviwZF7fEyTLrOBzOW1Hd4lPGCW jQDUcBT9R+5gD/2zifw3DV/NmfofWBWk9v6x+yz9Zaa8tI4qk3AtsQMO8JMBgCic mfTVVu58jXJG5RjZT/ElJBkxLv3FtpwKosBnj/juEzcZy8kjsqSH0tVNdSkoxuZF n90KFO2GUlViUZA= On 7 May 2010, at 11:08, Joel Reymont wrote: > On May 7, 2010, at 10:59 AM, Alastair Houghton wrote: > >> Personally, unless you have a really good justification for using jemalloc instead (and I'd argue that, for that, you need measurements showing that it's significantly faster than the system implementation), I'd stick with the system malloc. > > I get your point but let's just say this is something I've been tasked with. Apparently, the Javascript team discovered that too much time is being spent in free, or something like that. My goal is to plug in jemalloc and then let the Javascript team profile again. So maybe the solution is to look why the Javascript interpreter is releasing (and presumably allocating) so much? Or perhaps to consider whether giving it its own zone would be a useful thing to do (though you may very well not need to use a different allocation routine). Do you have the output from Shark for one of these cases to show you which code path it's hitting and where it's really spending its time? Kind regards, Alastair. -- http://alastairs-place.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: jemalloc to replace default allocator
by Alastair Houghton 07 May '10

07 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=coriolis-systems.com; h= subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=aug07; bh=FRaBXpHWZkmMAwBClHCXd25IQZM=; b=c9XWE5vwYDLnG/IlBmwEP9dEz7nN h9X8f7jW342pjwBHqdfRgH87pgTOsP4/DB6m9Qe7zwHwpOroVJA9irsg8i0+iJdM EWkarYz2V3YUt3+BYLd7skVc/FlHf3P0a53/PHFXKIEofvCYDFkfRb0GCaWxqUTd VXUWFg84S5/y1zo= On 7 May 2010, at 11:23, Jean-Daniel Dupas wrote: > Good advices, but how do you perform measurements without a way to replace the system allocator ;-) Indeed, I do realise that you could only *easily* perform artificial benchmarks. :-) Kind regards, Alastair. -- http://alastairs-place.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: jemalloc to replace default allocator
by Jean-Daniel Dupas 07 May '10

07 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0