Tamarin::MMgc: Difference between revisions

Jump to navigation Jump to search
m
→‎GCHeap: fmt, punct
No edit summary
 
m (→‎GCHeap: fmt, punct)
Line 575: Line 575:
The GC library has a tiered memory allocation strategy, consisting of 3 parts:
The GC library has a tiered memory allocation strategy, consisting of 3 parts:


# A page-granular memory allocator called the GCHeap
# A page-granular memory allocator called the <code>GCHeap</code>
# A set of fixed size allocators for sizes up to 2K
# A set of fixed size allocators for sizes up to 2K
# A large allocator for items over 2K
# A large allocator for items over 2K


When you want to allocate something we figure out what size class its in and then ask that allocator for the memory.  Each fixed size allocator maintains a doubly linked list of 4K blocks that it obtains from the GCHeap.  These 4k blocks are aligned on 4K boundaries so we can easily allocate everything on 8 byte boundaries (a necessary part of the 32 bit atom design, 3 type bits and 29 pointer bits).  Also we store the Block structure at the beginning of the 4K block so each allocation doesn't need a pointer to its block (just zero the lower 12 bits of any GC alloced thing to get the Block pointer).  The Block contains bitmaps for marking and indicating if an item has a destructor that needs to be called (a GCObject base class exists defining a virtual destructor for GC items that need it).  Deleted items are stored in a free list which is used if there are any otherwise we get the next free item at the end.  If we don't have anything free and we reach the end we get another block from the Heap.
When you want to allocate something we figure out what size class it's in and then ask that allocator for the memory.  Each fixed size allocator maintains a doubly linked list of 4K blocks that it obtains from the <code>GCHeap</code>.  These 4K blocks are aligned on 4K boundaries so we can easily allocate everything on 8-byte boundaries (a necessary consequence of the 32-bit atom design-- 3 type bits and 29 pointer bits).  Also we store the <code>GCAlloc::GCBlock</code> structure at the beginning of the 4K block so each allocation doesn't need a pointer to its block (just zero the lower 12 bits of any GC-allocated thing to get the <code>GCBlock</code> pointer).  The <code>GCBlock</code> contains bitmaps for marking and indicating if an item has a destructor that needs to be called (a <code>GCFinalizedObject</code> base class exists defining a virtual destructor for GC items that need it).  Deleted items are stored in a per-block free list which is used if there are any otherwise we get the next free item at the end.  If we don't have anything free and we reach the end, we get another block from the Heap.


== GCHeap's reserve/commit strategy ==
== GCHeap's reserve/commit strategy ==
638

edits

Navigation menu