base/allocator and tcmalloc

[Thiago Farina]

Hi list,

Does anyone knows or remember why we build third_party/tcmalloc in base/allocator?

I hit an issue related to this while doing https://codereview.chromium.org/638793002/

--

Thiago Farina

[Ryan Sleevi]

Can you provide more details? There's a lot of reasons, some fairly complicated. It is, without question, one of the most complicated set of dependencies in Chrome, due to very significant differences as to how one overrides the allocation system on Windows (ALL targets depend directly on it) vs Linux (ONLY executable targets should depend on it) and the complications that arise from our additional tools (like deep memory profiler)

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[William Chan (陈智昌)]

Here's a good minimal summary:
https://code.google.com/p/chromium/issues/detail?id=27911. There were
lots of complications due to the desired flexibility of different
allocators chosen at runtime/compiletime, some of which was only
captured offline between sgk@ & jar@. jar@ relayed some of it to me as
it pertained to POSIX, but I told him I wanted nothing to do with
their Windows craziness. Note that we no longer care about some of the
flexibility, although jar@ still likes the runtime allocator
flexibility for Windows, which we historically primarily used for
memory corruption debugging. I don't know if anyone actually uses it
today.

[Bruce Dawson]

At a previous job I changed our allocator system so that we could switch to the Windows heap without rebuilding (runtime allocator selection). This ended up being useful when we hit performance bugs in our allocator, for using Windows' pageheap, for using ETW heap profiling, and to make it easy to compare the performance and memory footprint of our allocator to Windows' allocator. I anticipate using that flexibility in Chrome at some point -- at least one of those uses should be applicable.

[William Chan (陈智昌)]

Indeed, you've nailed a subset of the reasons why we introduced the
runtime allocator selection in the first place. But it has its costs
too. Are you asserting that the benefits outweigh the costs?

[Sébastien Marchand]

Note that SyzyASan require using the Windows allocator (we intercept the kernel32!Heap* functions that it use internally), so removing it will affect us a lot.

Sébastien Marchand | Software Developer | sebma...@google.com 

[William Chan (陈智昌)]

But you just select the Windows allocator at compile time, right? Do
you rely on the runtime selection, and if so, why?

[Sébastien Marchand]

Well we still go through allocator_shim.cc (https://code.google.com/p/chromium/codesearch#chromium/src/base/allocator/allocator_shim.cc&l=39) , we just disable the allocator selection logic to force it to use WinHeap.

[William Chan (陈智昌)]

Let me know if I misread that, but it sounds like you don't need
runtime allocator selection. You just need to be able to control the
allocator.

On Wed, Oct 15, 2014 at 1:41 PM, Sébastien Marchand

[Sébastien Marchand]

Yeah exactly, we just need to be able to use Winheap.