On Tue, Oct 27, 2009 at 9:10 PM, Mike Belshe <mbel...@google.com> wrote:
> On Tue, Oct 27, 2009 at 3:24 PM, Jens Alfke <s...@chromium.org> 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.
Just thought I'd throw in the data point that I've experimented with
enabling tcmalloc for Linux builds of Chromium and the perfbots had
negligible changes. I haven't had time to investigate why. I'd
recommend you enable it for a run on the perfbots before you spend
much time tweaking the mac port of tcmalloc.
>
>>
>> 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: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
