Large block sizes are rounded up to the next multiple of HBLKSIZE and then allocated by -GC_allochblk. This uses roughly what Paul Wilson has termed -a "next fit" algorithm, i.e. first-fit with a rotating pointer. -The implementation does check for a better fitting immediately -adjacent block, which gives it somewhat better fragmentation characteristics. -I'm now convinced it should use a best fit algorithm. The actual +GC_allochblk. Recent versions of the collector +use an approximate best fit algorithm by keeping free lists for +several large block sizes. +The actual implementation of GC_allochblk is significantly complicated by black-listing issues (see below).
-Small blocks are allocated in blocks of size HBLKSIZE. -Each block is +Small blocks are allocated in chunks of size HBLKSIZE. +Each chunk is dedicated to only one object size and kind. The allocator maintains separate free lists for each size and kind of object.
+Once a large block is split for use in smaller objects, it can only +be used for objects of that size, unless the collector discovers a completely +empty chunk. Completely empty chunks are restored to the appropriate +large block free list. +
In order to avoid allocating blocks for too many distinct object sizes, the collector normally does not directly allocate objects of every possible request size. Instead request are rounded up to one of a smaller number @@ -139,27 +143,35 @@ expand the heap. Otherwise, we initiate a garbage col that the amount of garbage collection work per allocated byte remains constant.
-The above is in fat an oversimplification of the real heap expansion -heuristic, which adjusts slightly for root size and certain kinds of -fragmentation. In particular, programs with a large root set size and +The above is in fact an oversimplification of the real heap expansion +and GC triggering heuristic, which adjusts slightly for root size +and certain kinds of +fragmentation. In particular: +
-Versions 5.x of the collector actually collect more frequently in +scanning the roots. +
-(It has been suggested that this should be adjusted so that we favor +It has been suggested that this should be adjusted so that we favor expansion if the resulting heap still fits into physical memory. In many cases, that would no doubt help. But it is tricky to do this in a way that remains robust if multiple application are contending -for a single pool of physical memory.) +for a single pool of physical memory.
+The fact that it perform a only a small amount of work per call also +allows it to be used as the core routine of the parallel marker. In that +case it is normally invoked on thread-private mark stacks instead of the +global mark stack. More details can be found in +scale.html +
The marker correctly handles mark stack overflows. Whenever the mark stack overflows, the mark state is reset to MS_INVALID. Since there are already marked objects in the heap, @@ -281,7 +299,8 @@ Unmarked large objects are immediately returned to the Each small object page is checked to see if all mark bits are clear. If so, the entire page is returned to the large object free list. Small object pages containing some reachable object are queued for later -sweeping. +sweeping, unless we determine that the page contains very little free +space, in which case it is not examined further.
This initial sweep pass touches only block headers, not the blocks themselves. Thus it does not require significant paging, even @@ -341,12 +360,16 @@ object itself becomes marked, we have uncovered a cycle involving the object. This usually results in a warning from the collector. Such objects are not finalized, since it may be unsafe to do so. See the more detailed - discussion of finalization semantics. + discussion of finalization semantics.
Any objects remaining unmarked at the end of this process are added to a queue of objects whose finalizers can be run. Depending on collector configuration, finalizers are dequeued and run either implicitly during allocation calls, or explicitly in response to a user request. +(Note that the former is unfortunately both the default and not generally safe. +If finalizers perform synchronization, it may result in deadlocks. +Nontrivial finalizers generally need to perform synchronization, and +thus require a different collector configuration.)
The collector provides a mechanism for replacing the procedure that is used to mark through objects. This is used both to provide support for @@ -354,13 +377,14 @@ Java-style unordered finalization, and to ignore certa e.g. those arising from C++ implementations of virtual inheritance.
The most significant modification is that -the collector always runs in the allocating thread. -There is no separate garbage collector thread. +the collector always starts running in the allocating thread. +There is no separate garbage collector thread. (If parallel GC is +enabled, helper threads may also be woken up.) If an allocation attempt either requests a large object, or encounters an empty small object free list, and notices that there is a collection in progress, it immediately performs a small amount of marking work @@ -389,50 +413,108 @@ cannot be satisfied from small object free lists. When the set of modified pages is retrieved, and we mark once again from marked objects on those pages, this time with the mutator stopped.
-We keep track of modified pages using one of three distinct mechanisms: +We keep track of modified pages using one of several distinct mechanisms:
+During the mark phase, the collector tracks ``near misses'', i.e. attempts +to follow a ``pointer'' to just outside the garbage-collected heap, or +to a currently unallocated page inside the heap. Pages that have been +the targets of such near misses are likely to be the targets of +misidentified ``pointers'' in the future. To minimize the future +damage caused by such misidentifications they will be allocated only to +small pointerfree objects. +
+The collector understands two different kinds of black-listing. A +page may be black listed for interior pointer references +(GC_add_to_black_list_stack), if it was the target of a near +miss from a location that requires interior pointer recognition, +e.g. the stack, or the heap if GC_all_interior_pointers +is set. In this case, we also avoid allocating large blocks that include +this page. +
+If the near miss came from a source that did not require interior +pointer recognition, it is black-listed with +GC_add_to_black_list_normal. +A page black-listed in this way may appear inside a large object, +so long as it is not the first page of a large object. +
+The GC_allochblk routine respects black-listing when assigning +a block to a particular object kind and size. It occasionally +drops (i.e. allocates and forgets) blocks that are completely black-listed +in order to avoid excessively long large block free lists containing +only unusable blocks. This would otherwise become an issue +if there is low demand for small pointerfree objects. +
In particular, it is very difficult for the collector to stop all other threads in the system and examine the register contents. This is currently -accomplished with very different mechanisms for different Pthreads +accomplished with very different mechanisms for some Pthreads implementations. The Solaris implementation temporarily disables much of the user-level threads implementation by stopping kernel-level threads -("lwp"s). The Irix implementation sends signals to individual Pthreads -and has them wait in the signal handler. The Linux implementation -is similar in spirit to the Irix one. +("lwp"s). The Linux/HPUX/OSF1 and Irix implementations sends signals to +individual Pthreads and has them wait in the signal handler.
-The Irix implementation uses -only documented Pthreads calls, but relies on extensions to their semantics, -notably the use of mutexes and condition variables from signal -handlers. The Linux implementation should be far closer to -portable, though impirically it is not completely portable. +The Linux and Irix implementations use +only documented Pthreads calls, but rely on extensions to their semantics. +The Linux implementation linux_threads.c relies on only very +mild extensions to the pthreads semantics, and already supports a large number +of other Unix-like pthreads implementations. Our goal is to make this the +only pthread support in the collector.
+(The Irix implementation is separate only for historical reasons and should +clearly be merged. The current Solaris implementation probably performs +better in the uniprocessor case, but does not support thread operations in the +collector. Hence it cannot support the parallel marker.) +
All implementations must intercept thread creation and a few other thread-specific calls to allow enumeration of threads and location of thread stacks. This is current -accomplished with # define's in gc.h, or optionally +accomplished with # define's in gc.h +(really gc_pthread_redirects.h), or optionally by using ld's function call wrapping mechanism under Linux.
Comments are appreciated. Please send mail to -boehm@acm.org +boehm@acm.org or +Hans.Boehm@hp.com +
+This is a modified copy of a page written while the author was at SGI. +The original was here. +