I just submitted r33208, which changes the locations of the memory
allocation code that used to be all in third_party\tcmalloc.

Executive summary:  the new layout means you should (after updating) make
any memory allocation changes in the following locations:

    base\allocator:  mbelshe's shim layer that lets us choose between using
tcmalloc, jemalloc, the default Windows allocator, or the Windows
low-fragmentation-heap allocator

    third_party\jemalloc\chromium:  our copy of Jason Evans' jemalloc, the
allocator used by Firefox

    third_party\tcmalloc\chromium:  our copy of tcmalloc, our current
primary allocator on Windows and focus of most memory task force work

Code's the same, only the locations are different.  Copies of forked files
in the new scheme were branched (svn cp) from the old locations, so checkin
history should be preserved.

Why this change happened:

Our previous copy of tcmalloc used gclient to map in the upstream source
directly and forked copies of only the necessary files in a
locally-checked-in directory.  The tcmalloc code uses #include "file"
(double quotes) which has the unfortunate effect of *always* first looking
in the same directory as the source file.  This meant that we couldn't
correctly fork .h files, because (in essence) our forked files would use the
forked copies of .h files, and unforked files would still use the vanilla
upstream .h file.  (No, there's no way to change this compiler behavior with
/I or -I options, it's baked in.)

Details:

The "old" copies of the forked files still exist in their old location, to
make it easier to roll back if unintended side effects show up.  Once this
change has baked a few days, a follow-on cleanup CL will remove the copies
of forked files from their old locations, and also remove the "tcmalloc"
line from DEPS.

third_party\jemalloc\vendor and third_party\tcmalloc\vendor branches will
track upstream changes (checked in to make it a little more convenient to
diff and merge).

third_party\tcmalloc\README.chromium gives an overview of the steps for
taking a new upstream revision under this new layout.

Let me know if you notice problems or have questions.

        --SK

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

Reply via email to