Sadly, conservative collection has a fatal flaw: GC things cannot move. If something moved, you would need to update all pointers to that thing — but the conservative scanner can only tell you what might be a pointer, not what definitely is a pointer. Your program might be using an integer whose value happens to look like a pointer to a GC thing that is being moved, and updating that “pointer” will corrupt the value. Or you might have a string whose ASCII or UTF8 encoded values happen to look like a pointer, and updating that pointer will rewrite the string into a devastating personal insult.
So why do we care? Well, being able to move objects is a prerequisite for many advanced memory management facilities such as compacting and generational garbage collection. These techniques can produce dramatic improvements in collection pause times, allocation performance, and memory usage. SpiderMonkey would really like to be able to make use of these techniques. Unfortunately, after years of working with a conservative collector, we have accumulated a large body of code both inside SpiderMonkey and in the Gecko embedding that assumes a conservative scanner: pointers to GC things are littered all over the stack, tucked away in foreign data structures (i.e., data structures not managed by the GC), used as keys in hashtables, tagged with metadata in their lower bits, etc.
Over a year ago, the SpiderMonkey team began an effort to claw our way
back to an exact rooting scheme. The basic approach is to add a layer of
indirection to all GC thing pointer uses: rather than passing around
direct pointers to movable GC things, we pass around pointers to GC
thing pointers (“double pointers”, as in JSObject**). These Handles,
implemented with a C++ Handle<T> template type, introduce a small
cost to accesses since we now have to dereference twice to get to the
actual data rather than once. But it also means that we can update the
GC thing pointers at will, and all subsequent accesses will go to the
right place automatically.
http://www.math.nus.edu.sg/~mattyc/HeapSizing.pdf
This is an interesting paper. It more or less presents an equation,
H is the heap size, M is the size of available main memory
A garbage collection framework similar to the plai2 framework but less designed as a "toy" is the mmtk(Memory Management Toolkit) for the jikesRVM.
A quick overview of the interaction between the virtual machine and the mmtk framework can be found here: http://jikesrvm.org/Memory+Allocation+in+JikesRVM
Jikes is surprisingly both non-frightening and full-featured. One of the surprising things about MMTK is the presence of such optimizations as thread-local allocation interfaces while still retaining the simplicity of the memory manager interface.
If you're planning on making a collector for jikes, I believe that the best overview of the way that the collector is expected to be structured and how Jikes will use it can be found here: http://jikesrvm.org/Anatomy+of+a+Garbage+Collector
It comes with a large number of garbage collectors. They all satisfy a simple interface which captures the information that a collector needs.
Many of them will implement this interface, so it's worth looking at for the curious: http://jikesrvm.org/docs/api/org/mmtk/plan/Simple.html
There is a fairly straightforward tutorial on adding a simple mark-sweep collector and a quasi-generational hybrid copying/mark-sweep collector here: http://jikesrvm.org/MMTk+Tutorial
And I was glad to see that there was a comprehensive test harness for jikes. One of the most difficult things with plai2 is figuring out how to test things in isolation and together, and how to track test program misbehavior to a specific collector fault. http://jikesrvm.org/The+MMTk+Test+Harness The harness looks to be invaluable.
There's a canonical document here: http://cs.anu.edu.au/~Robin.Garner/mmtk-guide.pdf. While it appears to be unfinished and very empty, it does helpfully explain the naming convention used throughout the API.
Plans are ways of bring together collection, allocation, and heap policies into something that can be used by the MMTK. A plan is a package with classes for each of these.
A collection of regions of memory, each with a given allocation and collection policy.
MMTK currently supports write, but not read barriers.
A policy is a region of memory with a collection and allocation strategy.
| Name | Description |
| _gc_cause and _gc_lastcause, and _set_gc_cause | Records the causes when collections are triggered. Needs to be set to a "no cause" state between collections |
| _total_collections and _total_full_collections | |
| allocate_new_tlab(size), accumulate_statistics_all_tlabs, resize_all_tlabs, allocate_from_tlab | Interact with thread-local allocation buffers. |
| common_mem_allocate_noinit, common_mem_allocate_init | Allocate a block with the given size. Initialization means zeroing out |
| fill_with_array, fill_with_object_impl | Initialize array or object that's been allocated. |
| Name | The heap strategy being used. It's an enum mostly named for collector types. |
| Initialize, post_initialize | Initialize the "universe", and do other setup tasks before allocation |
| _is_maximal_no_gc | If the heap has reached it's maximum size allowed without a GC |
| max_capacity | The amount of memory the heap that the vm can allocate for java objects made by the user's code, and not used for bookkeeping |
| is_in_reserved, is_in_reserved_or_null | Whether the pointer is in the reserved heap region, and optionally is null |
| is_in_closed_subset, is_in_closed_subset_or_null | Is in a closed subset(all objects in subset point only to other objects in subset) |
| is_scavengable | Whether object can move during a scavenge(partial collection) |
| n_par_threads, set_par_threads | Number of threads currently working on gc tasks |
| Class_obj_allocate | Allocate and initialize an instance of a class |
| fill_with_objects, fill_with_object, etc | Fill allocated raw memory with object(s) and arrays |
| ensure_parseability | Place heap in a parseable state if not(in middle of GC) |
| unsafe_max_alloc | Estimate what can be allocated without possibly causing a collection |
| supports_tlab_alloc, tlab_capacity, tlab_max_alloc | Related functions for tlab interaction |
| can_elide_store_barriers | Whether the compiler can avoid a store barrier. If so, it must later call a deferring function to defer the store action. It must also later trigger a flush of these deferred stores. |
| collect, do_full_collection, collect_as_vm_thread | Various ways to request a collection, requiring various levels of locks |
| is_active? | Whether the world is stopped to collect, false for concurrent part of concurrent collectors |
| CollectorPolicy, AdaptiveSizePolicy | The policies the heap has for collection and resizing, with associated costs for actions. |
| millis_since_last_gc | Time since last GC |
| print_gc_threads, print_all_gc_threads, trace_all_threads | Print / trace / debug threads |
| use_parallel_gc_threads | Whether parallel threads are being used |
