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. 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 -~----------~----~----~----~------~----~------~--~---
