 |
CVM Garbage Collector
GC Selection
CVM has a pluggable GC interface which allows the VM builder to install an
alternate GC implementation at build-time (i.e. via static linking only).
Currently, the GC type cannot be changed at runtime or VM launch time.
The choice of GC is specified in the make process using CVM_GCCHOICE. By default,
CVM_GCCHOICE=generational.
GC Choices
The current default and only supported GC is the Generational GC.
The generational GC is set up with 2 generations:
- young generation (youngGen): a semispace copier collector
- old generation (oldGen): a mark-compact collector
Other GC choices are all experimental (and therefore not supported) code. These
GCs are not fully tested and are known to have bugs. They are provided as examples
of how to use the pluggable GC interface rather than examples of usable GCs.
These GCs are:
- Segmented Generational GC (CVM_GCCHOICE=generational-seg)
Consists or 3 generations:
- eden generation (edenGen): single space eden
- young generation (youngGen): a semispace copier survivor space
- old generation (oldGen): a mark-compact collector
This GC attempts to implement a resizable heap using chunky allocation.
- MarkSweep GC (CVM_GCCHOICE=marksweep)
A non-compacting mark sweep collector. Objects are freed into a free list.
- SemiSpace GC (CVM_GCCHOICE=semispace)
A semispace copier collector.
The rest of this document will talk solely about the Generational GC implementation.
YoungGen Root Scans
Previously, the youngGen uses Cheney scanning i.e. it uses the new semispace as a queue
of objects to scan. Live objects in the old semispace are copied over to the new
semispace to be scanned later. However, this results in breadth-first scanning of
child objects.
It was discovered that depth-first scanning can have very positive effects on
application code performance because depth-first scanning creates better data cache
locality. The youngGen now does depth-first scans.
Resizing the heap
Currently, only the oldGen can be resized at runtime. Resizing is done using the
underlying OS's memory mapping capabilities. At VM boot time, the GC reserves a
contiguous region of memory for its heap. As needed, some portion of this region
is committed (i.e. physical memory is assigned to it). This mechanism is only
possible in the presence of a virtual memory manager.
If virtual memory management is not available, the heap implementation falls back
on malloc'ing the entire region in one go. Hence, the heap will be fixed sized,
and the size is determined during heap initialization at VM boot time.
-- Main.prasadsanagavarapu - 12 Nov 2006
|