On Tue, Oct 27, 2009 at 9:10 PM, Mike Belshe <[email protected]> wrote:
> On Tue, Oct 27, 2009 at 3:24 PM, Jens Alfke <[email protected]> wrote: > >> Do we plan to switch the Mac build of Chromium to use tcmalloc instead of >> the system malloc? I thought this was the case, but I can't find any bug >> covering the task to do that. I'm on the memory task force, and this >> decision could definitely have an impact (one direction or the other) on >> footprint on Mac. >> > > From a performance perspective, it may be critical to use tcmalloc to match > safari performance. It was literally a 50% speedup on most of the DOM perf > when running on WinXP. > > >> >> I just tried enabling tcmalloc (by changing USE_SYSTEM_MALLOC to 0 in >> JavaScriptCore.gyp), and Chromium launches but logs a ton of warnings about >> unknown pointers being freed. >> > > I suspect this will use the version of TCMalloc which is embedded in WTF. > I'd recommend against this approach. We should try to use a single > allocator for the entire app, and specialize when necessary. Having the > rendering engine drive the allocator is a bit backwards; it seems better for > chrome itself to choose the allocator and then the rendering engine should > use that. > +1 I'm pretty sure that enabling USE_SYSTEM_MALLOC will also lead to corruption since WebKit is not hermetic (we allocate things externally that we then delete inside WebKit). -Darin > > To make this work, you'll need to figure out whatever build magic is > necessary on the Mac; I'm kinda clueless in that regard, but if you want to > know what we did on Windows, I'm happy to share. > > You'll find the tcmalloc version that we use on windows available in > third_party/tcmalloc. > > Keep in mind also that the version of tcmalloc in webcore is heavily > modified by apple. Some of those changes have been similarly made in > tcmalloc's open source project, but others have not. Apple has not seemed > interested in syncing back and appears to be on the "fork it" route. > > Using third_party/tcmalloc will offer a couple of advantages: > - we are continuing to improve it all the way from google3 to the > google-perftools to chrome. > - it will provide the same allocator on windows and mac (easier > debugging) > - the chromium implementation allows for selection of multiple > allocators fairly easily. Using the allocator_shim.cc, you can plug in your > own allocators pretty quickly. > > There is a disadvantage. I suspect Apple is farther along in optimizing > the mac-specific optimizations of tcmalloc than the google3 guys are. You > may have to stumble into these. Either Jim or I could probably give you > some pointers for what to look at. tcmalloc is solid, but the ports other > than linux have had some very serious port related bugs. > > Mike > > > >> >> I think this happens because tcmalloc is built by the 'wtf' target of >> JavaScriptCore.xcodeproj, which is a *static* library, so we may be >> ending up with multiple instances of the library with their own copies of >> its globals, leading to this problem if one instance allocates a block and >> another one tries to free it. But this usually happens only if there are >> multiple dynamic libraries using the same static library — do we have more >> than just Chromium.framework? >> >> —Jens >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
