Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(6)

Unified Diff: base/allocator/README

Issue 434067: Branch the files in the shim layer that switches between the... (Closed) Base URL: svn://chrome-svn/chrome/trunk/src/
Patch Set: Created 11 years, 1 month ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
« no previous file with comments | « no previous file | base/allocator/allocator.gyp » ('j') | no next file with comments »
Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
Index: base/allocator/README
===================================================================
--- base/allocator/README (revision 0)
+++ base/allocator/README (working copy)
@@ -1,60 +1,59 @@
-Notes about the Chrome port of tcmalloc & jemalloc.
-
-Background
-----------
-We use this library as a generic way to fork into any of several allocators.
-Currently we can, at runtime, switch between:
- the default windows allocator
- the windows low-fragmentation-heap
- tcmalloc
- jemalloc (the heap used most notably within Mozilla Firefox)
-
-The mechanism for hooking LIBCMT in windows is rather tricky. The core
-problem is that by default, the windows library does not declare malloc and
-free as weak symbols. Because of this, they cannot be overriden. To work
-around this, we start with the LIBCMT.LIB, and manually remove all allocator
-related functions from it using the visual studio library tool. Once removed,
-we can now link against the library and provide custom versions of the
-allocator related functionality.
-
-
-Source code
------------
-Everything within the directory tcmalloc/tcmalloc is pulled directly from the
-google-perftools repository. For the most part, tcmalloc is a stock build
-from there.
-
-We have forked a few files. We always push our changes upstream, so over
-time the forked files should disappear. Currently forked files include:
- page_heap.cc
- port.cc
- system-alloc.cc
- system-alloc.h
- tcmalloc.cc
-
-Adding a new allocator requires definition of the following five functions:
- extern "C" {
- bool init();
- void* malloc(size_t s);
- void* realloc(void* p, size_t s);
- void free(void* s);
- size_t msize(void* p);
- }
-
-All other allocation related functions (new/delete/calloc/etc) have been
-implemented generically to work across all allocators.
-
-
-Usage
------
-You can use the different allocators by setting the environment variable
-CHROME_ALLOCATOR to:
- "tcmalloc" - TC Malloc (default)
- "jemalloc" - JE Malloc
- "winheap" - Windows default heap
- "winlfh" - Windows Low-Fragmentation heap
-
-
-Local modifications
--------------------
-jemalloc has been modified slightly to work within the Chromium build.
+Notes about the Chrome memory allocator.
+
+Background
+----------
+We use this library as a generic way to fork into any of several allocators.
+Currently we can, at runtime, switch between:
+ the default windows allocator
+ the windows low-fragmentation-heap
+ tcmalloc
+ jemalloc (the heap used most notably within Mozilla Firefox)
+
+The mechanism for hooking LIBCMT in windows is rather tricky. The core
+problem is that by default, the windows library does not declare malloc and
+free as weak symbols. Because of this, they cannot be overriden. To work
+around this, we start with the LIBCMT.LIB, and manually remove all allocator
+related functions from it using the visual studio library tool. Once removed,
+we can now link against the library and provide custom versions of the
+allocator related functionality.
+
+
+Source code
+-----------
+This directory contains just the allocator (i.e. shim) layer that switches
+between the different underlying memory allocation implementations.
+
+The tcmalloc and jemalloc libraries originate outside of Chromium
+and exist in ../../third_party/tcmalloc and ../../third_party/jemalloc
+(currently, the actual locations are defined in the allocator.gyp file).
+The third party sources use a vendor-branch SCM pattern to track
+Chromium-specific changes independently from upstream changes.
+
+The general intent is to push local changes upstream so that over
+time we no longer need any forked files.
+
+
+Adding a new allocator
+----------------------
+Adding a new allocator requires definition of the following five functions:
+
+ extern "C" {
+ bool init();
+ void* malloc(size_t s);
+ void* realloc(void* p, size_t s);
+ void free(void* s);
+ size_t msize(void* p);
+ }
+
+All other allocation related functions (new/delete/calloc/etc) have been
+implemented generically to work across all allocators.
+
+
+Usage
+-----
+You can use the different allocators by setting the environment variable
+CHROME_ALLOCATOR to:
+ "tcmalloc" - TC Malloc (default)
+ "jemalloc" - JE Malloc
+ "winheap" - Windows default heap
+ "winlfh" - Windows Low-Fragmentation heap
Property changes on: base\allocator\README
___________________________________________________________________
Added: svn:eol-style
+ LF
« no previous file with comments | « no previous file | base/allocator/allocator.gyp » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698