$(DDOC $(DDOC_BLANKLINE )
$(DDOC_BLANKLINE )
$(SPEC_S Garbage Collection,
$(DDOC_BLANKLINE )
$(HEADERNAV_TOC $(HEADERNAV_ITEM how_gc_works, How Garbage Collection Works)
$(HEADERNAV_ITEM gc_foreign_obj, Interfacing Garbage Collected Objects With Foreign Code)
$(HEADERNAV_ITEM pointers_and_gc, Pointers and the Garbage Collector)
$(HEADERNAV_ITEM working_with_the_gc, Working with the Garbage Collector)
$(HEADERNAV_ITEM obj_pinning_and_gc, Object Pinning and a Moving Garbage Collector)
$(HEADERNAV_ITEM gc_config, Configuring the Garbage Collector)
$(HEADERNAV_ITEM precise_gc, Precise Heap Scanning)
$(HEADERNAV_ITEM precise_dataseg, Precise Scanning of the DATA and TLS segment)
$(HEADERNAV_ITEM gc_parallel, Parallel marking)
$(HEADERNAV_ITEM gc_registry, Adding your own Garbage Collector)
$(HEADERNAV_ITEM references, References)
)
$(DDOC_BLANKLINE )
$(P D is a systems programming language with support for garbage collection.
Usually it is not necessary
to free memory explicitly. Just allocate as needed, and the garbage collector will
periodically return all unused memory to the pool of available memory.
)
$(DDOC_BLANKLINE )
$(P D also provides the mechanisms to write code where the garbage collector
is $(B not involved). More information is provided below.
)
$(DDOC_BLANKLINE )
$(P Programmers accustomed to explicitly managing memory
allocation and
deallocation will likely be skeptical of the benefits and efficacy of
garbage collection. Experience both with new projects written with
garbage collection in mind, and converting existing projects to garbage
collection shows that:
)
$(DDOC_BLANKLINE )
$(UL $(DDOC_BLANKLINE )
$(LI Garbage collected programs are often faster. This is
counterintuitive, but the reasons are:
$(DDOC_BLANKLINE )
$(UL $(LI Reference counting is a common solution to solve explicit
memory allocation problems. The code to implement the increment and
decrement operations whenever assignments are made is one source
of slowdown. Hiding it behind smart pointer classes doesn't help
the speed. (Reference counting methods are not a general solution
anyway, as circular references never get deleted.)
)
$(DDOC_BLANKLINE )
$(LI Destructors are used to deallocate resources acquired by an object.
For most classes, this resource is allocated memory.
With garbage collection, most destructors then become empty and
can be discarded entirely.
)
$(DDOC_BLANKLINE )
$(LI All those destructors freeing memory can become significant when
objects are allocated on the stack. For each one, some mechanism must
be established so that if an exception happens, the destructors all
get called in each frame to release any memory they hold. If the
destructors become irrelevant, then there's no need to set up special
stack frames to handle exceptions, and the code runs faster.
)
$(DDOC_BLANKLINE )
$(LI Garbage collection kicks in only when memory gets tight. When
memory is not tight, the program runs at full speed and does not
spend any time tracing and freeing memory.
)
$(DDOC_BLANKLINE )
$(LI Garbage collected programs do not suffer from gradual deterioration
due to an accumulation of memory leaks.
)
)
)
$(DDOC_BLANKLINE )
$(LI Garbage collectors reclaim unused memory, therefore they do not suffer
from "memory leaks" which can cause long running applications to gradually
consume more and more memory until they bring down the system. GC programs
have longer term stability.
)
$(DDOC_BLANKLINE )
$(LI Garbage collected programs have fewer hard-to-find pointer bugs. This
is because there are no dangling references to freed memory. There is no
code to explicitly manage memory, hence no bugs in such code.
)
$(DDOC_BLANKLINE )
$(LI Garbage collected programs are faster to develop and debug, because
there's no need for developing, debugging, testing, or maintaining the
explicit deallocation code.
)
$(DDOC_BLANKLINE )
)
$(DDOC_BLANKLINE )
$(P Garbage collection is not a panacea. There are some downsides:
)
$(DDOC_BLANKLINE )
$(UL $(DDOC_BLANKLINE )
$(LI It is not always obvious when the GC allocates memory, which in
turn can trigger a collection, so the program can pause unexpectedly.
)
$(DDOC_BLANKLINE )
$(LI The time it takes for a collection to complete is not bounded.
While in practice it is very quick, this cannot normally be guaranteed.
)
$(DDOC_BLANKLINE )
$(LI Normally, all threads other than the collector thread must be
halted while the collection is in progress.
)
$(DDOC_BLANKLINE )
$(LI Garbage collectors can keep around some memory that an explicit
deallocator would not.
)
$(DDOC_BLANKLINE )
$(LI Garbage collection should be implemented as a basic operating
system
kernel service. But since it is not, garbage collecting programs must
carry around with them the garbage collection implementation. While this
can be a shared library, it is still there.
)
)
$(DDOC_BLANKLINE )
$(P These constraints are addressed by techniques outlined
in $(LINK2 https://wiki.dlang.org/Memory_Management, Memory Management), including the mechanisms provided by
D to control allocations outside the GC heap.
)
$(DDOC_BLANKLINE )
$(P There is currently work in progress to make the runtime library free of GC heap allocations,
to allow its use in scenarios where the use of GC infrastructure is not possible.
)
$(DDOC_BLANKLINE )
$(LNAME2 how_gc_works, How Garbage Collection Works)
$(DDOC_BLANKLINE )
$(P The GC works by:)
$(DDOC_BLANKLINE )
$(OL $(LI Stopping all other threads than the thread currently trying to
allocate GC memory.)
$(DDOC_BLANKLINE )
$(LI $(SINGLEQUOTE Hijacking) the current thread for GC work.)
$(DDOC_BLANKLINE )
$(LI Scanning all $(SINGLEQUOTE root) memory ranges for pointers into
GC allocated memory.)
$(DDOC_BLANKLINE )
$(LI Recursively scanning all allocated memory pointed to by
roots looking for more pointers into GC allocated memory.)
$(DDOC_BLANKLINE )
$(LI Freeing all GC allocated memory that has no active pointers
to it and do not need destructors to run.)
$(DDOC_BLANKLINE )
$(LI Queueing all unreachable memory that needs destructors to run.)
$(DDOC_BLANKLINE )
$(LI Resuming all other threads.)
$(DDOC_BLANKLINE )
$(LI Running destructors for all queued memory.)
$(DDOC_BLANKLINE )
$(LI Freeing any remaining unreachable memory.)
$(DDOC_BLANKLINE )
$(LI Returning the current thread to whatever work it was doing.)
)
$(DDOC_BLANKLINE )
$(LNAME2 gc_foreign_obj, Interfacing Garbage Collected Objects With Foreign Code)
$(DDOC_BLANKLINE )
$(P The garbage collector looks for roots in:)
$(OL $(LI the static data segment)
$(LI the stacks and register contents of each thread)
$(LI the TLS (thread-local storage) areas of each thread)
$(LI any roots added by core.memory.GC.addRoot() or core.memory.GC.addRange())
)
$(DDOC_BLANKLINE )
$(P If the only pointer to an object
is held outside of these areas, then the collector will miss it and free the
memory.
)
$(DDOC_BLANKLINE )
$(P To avoid this from happening, either)
$(DDOC_BLANKLINE )
$(UL $(LI maintain a pointer to the object in an area the collector does scan
for pointers;)
$(DDOC_BLANKLINE )
$(LI add a root where a pointer to the object is stored using core.memory.GC.addRoot()
or core.memory.GC.addRange().)
$(DDOC_BLANKLINE )
$(LI reallocate and copy the object using the foreign code's storage
allocator
or using the C runtime library's malloc/free.
)
)
$(DDOC_BLANKLINE )
$(LNAME2 pointers_and_gc, Pointers and the Garbage Collector)
$(DDOC_BLANKLINE )
$(P Pointers in D can be broadly divided into two categories: Those that
point to garbage collected memory, and those that do not. Examples
of the latter are pointers created by calls to C's malloc(), pointers
received from C library routines, pointers to static data,
pointers to objects on the stack, etc. For those pointers, anything
that is legal in C can be done with them.
)
$(DDOC_BLANKLINE )
$(P For garbage collected pointers and references, however, there are
some
restrictions. These restrictions are minor, but they are intended
to enable the maximum flexibility in garbage collector design.
)
$(DDOC_BLANKLINE )
$(UNDEFINED_BEHAVIOR $(DDOC_BLANKLINE )
$(UL $(DDOC_BLANKLINE )
$(LI Do not xor pointers with other values, like the
xor pointer linked list trick used in C.
)
$(DDOC_BLANKLINE )
$(LI Do not use the xor trick to swap two pointer values.
)
$(DDOC_BLANKLINE )
$(LI Do not store pointers into non-pointer variables using casts and
other tricks.
$(DDOC_BLANKLINE )
$(D_CODE $(D_KEYWORD void)* p;
...
$(D_KEYWORD int) x = $(D_KEYWORD cast)($(D_KEYWORD int))p; $(D_COMMENT // error: undefined behavior
))
$(DDOC_BLANKLINE )
The garbage collector does not scan non-pointer fields for GC pointers.
)
$(DDOC_BLANKLINE )
$(LI Do not take advantage of alignment of pointers to store bit flags
in the low order bits:
$(DDOC_BLANKLINE )
$(D_CODE p = $(D_KEYWORD cast)($(D_KEYWORD void)*)($(D_KEYWORD cast)($(D_KEYWORD int))p | 1); $(D_COMMENT // error: undefined behavior
))
)
$(DDOC_BLANKLINE )
$(LI Do not store into pointers values that may point into the
garbage collected heap:
$(DDOC_BLANKLINE )
$(D_CODE p = $(D_KEYWORD cast)($(D_KEYWORD void)*)12345678; $(D_COMMENT // error: undefined behavior
))
$(DDOC_BLANKLINE )
A copying garbage collector may change this value.
)
$(DDOC_BLANKLINE )
$(LI Do not store magic values into pointers, other than $(D null).
)
$(DDOC_BLANKLINE )
$(LI Do not write pointer values out to disk and read them back in
again.
)
$(DDOC_BLANKLINE )
$(LI Do not use pointer values to compute a hash function. A copying
garbage collector can arbitrarily move objects around in memory,
thus invalidating
the computed hash value.
)
$(DDOC_BLANKLINE )
$(LI Do not depend on the ordering of pointers:
$(DDOC_BLANKLINE )
$(D_CODE $(D_KEYWORD if) (p1 < p2) $(D_COMMENT // error: undefined behavior
) ...
)
since, again, the garbage collector can move objects around in
memory.
)
$(DDOC_BLANKLINE )
$(LI Do not add or subtract an offset to a pointer such that the result
points outside of the bounds of the garbage collected object originally
allocated.
$(DDOC_BLANKLINE )
$(D_CODE $(D_KEYWORD char)* p = $(D_KEYWORD new) $(D_KEYWORD char)[10];
$(D_KEYWORD char)* q = p + 6; $(D_COMMENT // ok
)q = p + 11; $(D_COMMENT // error: undefined behavior
)q = p - 1; $(D_COMMENT // error: undefined behavior
))
)
$(DDOC_BLANKLINE )
$(LI Do not misalign pointers if those pointers may
point into the GC heap, such as:
$(DDOC_BLANKLINE )
$(D_CODE $(D_KEYWORD struct) Foo
{
$(D_KEYWORD align) (1):
$(D_KEYWORD byte) b;
$(D_KEYWORD char)* p; $(D_COMMENT // misaligned pointer
)}
)
$(DDOC_BLANKLINE )
Misaligned pointers may be used if the underlying hardware
supports them $(B and) the pointer is never used to point
into the GC heap.
)
$(DDOC_BLANKLINE )
$(LI Do not use byte-by-byte memory copies to copy pointer values.
This may result in intermediate conditions where there is
not a valid pointer, and if the GC pauses the thread in such a
condition, it can corrupt memory.
Most implementations of $(D memcpy()) will work since the
internal implementation of it does the copy in aligned chunks
greater than or equal to the pointer size, but since this kind of
implementation is not guaranteed by the C standard, use
$(D memcpy()) only with extreme caution.
)
$(DDOC_BLANKLINE )
$(LI Do not have pointers in a struct instance that point back
to the same instance. The trouble with this is if the instance
gets moved in memory, the pointer will point back to where it
came from, with likely disastrous results.
)
$(DDOC_BLANKLINE )
)
)
$(DDOC_BLANKLINE )
$(P Things that are reliable and can be done:)
$(DDOC_BLANKLINE )
$(UL $(DDOC_BLANKLINE )
$(LI Use a union to share storage with a pointer:
$(DDOC_BLANKLINE )
$(D_CODE $(D_KEYWORD union) U { $(D_KEYWORD void)* ptr; $(D_KEYWORD int) value }
)
)
$(DDOC_BLANKLINE )
$(LI A pointer to the start of a garbage collected object need not
be maintained if a pointer to the interior of the object exists.
$(DDOC_BLANKLINE )
$(D_CODE $(D_KEYWORD char)[] p = $(D_KEYWORD new) $(D_KEYWORD char)[10];
$(D_KEYWORD char)[] q = p[3..6];
$(D_COMMENT // q is enough to hold on to the object, don't need to keep
)$(D_COMMENT // p as well.
))
)
)
$(DDOC_BLANKLINE )
$(P One can avoid using pointers anyway for most tasks. D provides
features
rendering most explicit pointer uses obsolete, such as reference
objects,
dynamic arrays, and garbage collection. Pointers
are provided in order to interface successfully with C APIs and for
some low level work.
)
$(DDOC_BLANKLINE )
$(LNAME2 working_with_the_gc, Working with the Garbage Collector)
$(DDOC_BLANKLINE )
$(P Garbage collection doesn't solve every memory deallocation problem.
For
example, if a pointer to a large data structure is kept, the garbage
collector cannot reclaim it, even if it is never referred to again. To
eliminate this problem, it is good practice to set a reference or
pointer to an object to null when no longer needed.
)
$(DDOC_BLANKLINE )
$(P This advice applies only to static references or references embedded
inside other objects. There is not much point for such stored on the
stack to be nulled because new stack frames are initialized anyway.
)
$(DDOC_BLANKLINE )
$(LNAME2 obj_pinning_and_gc, Object Pinning and a Moving Garbage Collector)
$(DDOC_BLANKLINE )
$(P Although D does not currently use a moving garbage collector, by following
the rules listed above one can be implemented. No special action is required
to pin objects. A moving collector will only move objects for which there
are no ambiguous references, and for which it can update those references.
All other objects will be automatically pinned.
)
$(DDOC_BLANKLINE )
D $(LNAME2 op_involving_gc, Operations That Involve the Garbage Collector)
$(DDOC_BLANKLINE )
$(P Some sections of code may need to avoid using the garbage collector.
The following constructs may allocate memory using the garbage collector:
)
$(DDOC_BLANKLINE )
$(UL $(LI $(GLINK2 expression, NewExpression))
$(LI Array appending)
$(LI Array concatenation)
$(LI Array literals (except when used to initialize static data))
$(LI Associative array literals)
$(LI Any insertion or removal in an associative array)
$(LI Extracting keys or values from an associative array)
$(LI Taking the address of (i.e. making a delegate to) a nested function that
accesses variables in an outer scope)
$(LI A function literal that accesses variables in an outer scope)
$(DDOC_BLANKLINE )
$(LI An $(GLINK2 expression, AssertExpression) that fails its condition)
)
$(DDOC_BLANKLINE )
$(LNAME2 gc_config, Configuring the Garbage Collector)
$(DDOC_BLANKLINE )
$(P Since version 2.067, The garbage collector can now be configured
through the command line, the environment or by options embedded
into the executable.
)
$(DDOC_BLANKLINE )
$(P By default, GC options can only be passed on the command line of the program
to run, e.g.)
$(DDOC_BLANKLINE )
$(D_CODE app $(D_STRING "--DRT-gcopt=profile:1 minPoolSize:16") arguments to app
)
$(DDOC_BLANKLINE )
$(P Available GC options are:)
$(UL $(LI disable:0|1 - start disabled)
$(LI profile:0|1 - enable profiling with summary when terminating program)
$(LI gc:conservative|precise|manual - select GC implementation (default = conservative))
$(LI initReserve:N - initial memory to reserve in MB)
$(LI minPoolSize:N - initial and minimum pool size in MB)
$(LI maxPoolSize:N - maximum pool size in MB)
$(LI incPoolSize:N - pool size increment MB)
$(LI parallel:N - number of additional threads for marking)
$(LI heapSizeFactor:N - targeted heap size to used memory ratio)
$(LI cleanup:none|collect|finalize - how to treat live objects when terminating
$(UL $(LI collect: run a collection (the default for backward compatibility))
$(LI none: do nothing)
$(LI finalize: all live objects are finalized unconditionally)
)
))
$(DDOC_BLANKLINE )
$(DDOC_BLANKLINE )
$(P In addition, --DRT-gcopt=help will show the list of options and their current settings.
)
$(P Command line options starting with "--DRT-" are filtered out before calling main,
so the program will not see them. They are still available via rt_args
.
)
$(P Configuration via the command line can be disabled by declaring a variable for the
linker to pick up before using its default from the runtime:)
$(D_CODE $(D_KEYWORD extern)(C) $(D_KEYWORD __gshared) $(D_KEYWORD bool) rt_cmdline_enabled = $(D_KEYWORD false);
)
$(DDOC_BLANKLINE )
$(P Likewise, declare a boolean rt_envvars_enabled
to enable configuration via the
environment variable DRT_GCOPT
:)
$(D_CODE $(D_KEYWORD extern)(C) $(D_KEYWORD __gshared) $(D_KEYWORD bool) rt_envvars_enabled = $(D_KEYWORD true);
)
$(DDOC_BLANKLINE )
$(P Setting default configuration properties in the executable can be done by specifying an
array of options named rt_options
:)
$(D_CODE $(D_KEYWORD extern)(C) $(D_KEYWORD __gshared) string[] rt_options = [ $(D_STRING "gcopt=initReserve:100 profile:1") ];
)
$(DDOC_BLANKLINE )
$(P Evaluation order of options is rt_options
, then environment variables, then command
line arguments, i.e. if command line arguments are not disabled, they can override
options specified through the environment or embedded in the executable.
)
$(DDOC_BLANKLINE )
$(LNAME2 precise_gc, Precise Heap Scanning)
$(DDOC_BLANKLINE )
$(P Selecting precise
as the garbage collector via the options above means type
information will be used to identify actual or possible pointers or
references within heap allocated data objects. Non-pointer data will not
be interpreted as a reference to other memory as a "false pointer". The collector
has to make pessimistic assumptions if a memory slot can contain both a pointer or
an integer value, it will still be scanned (e.g. in a union
).
)
$(DDOC_BLANKLINE )
$(P To use the GC memory functions from core.memory
for data with a mixture of pointers and non-pointer data, pass the
TypeInfo of the allocated struct, class, or type as the optional parameter.
The default null
is interpreted as memory that might contain pointers everywhere.)
$(D_CODE $(D_KEYWORD struct) S { size_t hash; Data* data; }
S* s = $(D_KEYWORD cast)(S*)GC.malloc(S.sizeof, 0, $(D_KEYWORD typeid)(S));
)
$(DDOC_BLANKLINE )
$(P $(RED Attention:) Enabling precise scanning needs slightly more caution with
type declarations. For example, when reserving a buffer as part of a struct and later
emplacing an object instance with references to other allocations into this memory,
do not use basic integer types to reserve the space. Doing so will cause the
garbage collector not to detect the references. Instead, use an array type that
will scan this area conservatively. Using void*
is usually the best option as it also
ensures proper alignment for pointers being scanned by the GC.
)
$(DDOC_BLANKLINE )
$(LNAME2 precise_dataseg, Precise Scanning of the DATA and TLS segment)
$(DDOC_BLANKLINE )
$(P $(B Windows only:) As of version 2.075, the DATA (global shared data)
and TLS segment (thread local data) of an executable
or DLL can be configured to be scanned precisely by the garbage collector
instead of conservatively. This takes
advantage of information emitted by the compiler to
identify possible mutable pointers inside these segments. Immutable pointers
$(DDSUBLINK spec/const3, immutable_storage_class, with initializers)
are excluded from scanning, too, as they can only point to preallocated memory.
)
$(DDOC_BLANKLINE )
$(P Precise scanning can be enabled with the D runtime option "scanDataSeg". Possible option
values are "conservative" (default) and "precise". As with the GC options, it can be
specified on the command line, in the environment or embedded into the executable, e.g.)
$(D_CODE $(D_KEYWORD extern)(C) $(D_KEYWORD __gshared) string[] rt_options = [ $(D_STRING "scanDataSeg=precise") ];
)
$(DDOC_BLANKLINE )
$(DDOC_BLANKLINE )
$(P $(RED Attention:) Enabling precise scanning needs slightly more caution typing
global memory. For example, to pre-allocate memory in the DATA/TLS segment and later
emplace an object instance with references to other allocations into this memory,
do not use basic integer types to reserve the space. Doing so will cause the
garbage collector not to detect the references. Instead, use an array type that
will scan this area conservatively. Using void*
is usually the best option as it also
ensures proper alignment for pointers being scanned by the GC.)
$(D_CODE $(D_KEYWORD class) Singleton { $(D_KEYWORD void)[] mem; }
$(D_KEYWORD align)($(D_KEYWORD __traits)(classInstanceAlignment, Singleton))
$(D_KEYWORD void)*[($(D_KEYWORD __traits)(classInstanceSize, Singleton) - 1) / ($(D_KEYWORD void)*).sizeof + 1]
singleton_store;
$(D_KEYWORD static) $(D_KEYWORD this)()
{
emplace!Singleton(singleton_store).mem = allocateMem();
}
Singleton singleton() { $(D_KEYWORD return) $(D_KEYWORD cast)(Singleton)singleton_store.ptr; }
)
For precise typing of that area, let the compiler generate the class
instance into the DATA segment:
$(D_CODE $(D_KEYWORD class) Singleton { $(D_KEYWORD void)[] mem; }
$(D_KEYWORD shared)(Singleton) singleton = $(D_KEYWORD new) Singleton;
$(D_KEYWORD shared) $(D_KEYWORD static) $(D_KEYWORD this)() { singleton.mem = allocateSharedMem(); }
)
This doesn't work for TLS memory, though.
$(DDOC_BLANKLINE )
$(LNAME2 gc_parallel, Parallel marking)
$(DDOC_BLANKLINE )
$(P By default the garbage collector uses all available CPU cores to mark the heap.)
$(DDOC_BLANKLINE )
$(P This might affect your application if it has threads that are not suspended
during the mark phase of the collection. Configure the number of
additional threads used for marking by GC option parallel
,
e.g. by passing --DRT-gcopt=parallel:2
on the command
line or embedding the option into the binary via rt_options
.
The number of threads actually created is limited to
$(LINK2 $(ROOT_DIR )library/core/cpuid/threads_per_cpu.html, core.cpuid.threadsPerCPU-1
).
A value of 0
disables parallel marking completely.)
$(DDOC_BLANKLINE )
$(LNAME2 gc_registry, Adding your own Garbage Collector)
$(DDOC_BLANKLINE )
$(P GC implementations are added to a registry that allows to supply
more implementations by just linking them into
the binary. To do so add a function that is executed before the
D runtime initialization using pragma(crt_constructor)
:)
$(D_CODE $(D_KEYWORD import) core.gc.gcinterface, core.gc.registry;
$(D_KEYWORD extern) (C) $(D_KEYWORD pragma)(crt_constructor) $(D_KEYWORD void) registerMyGC()
{
registerGCFactory($(D_STRING "mygc"), &createMyGC);
}
GC createMyGC()
{
$(D_KEYWORD __gshared) instance = $(D_KEYWORD new) MyGC;
instance.initialize();
$(D_KEYWORD return) instance;
}
$(D_KEYWORD class) MyGC : GC { $(D_COMMENT /*...*/) }
)
$(DDOC_BLANKLINE )
$(P [The GC modules defining the interface (gc.interface) and registration
(gc.registry) are currently not public and are subject to
change from version to version. Add an import search path to the
druntime/src path to compile the example.])
$(DDOC_BLANKLINE )
$(P The new GC is added to the list of available garbage collectors that
can be selected via the usual configuration options, e.g. by embedding
rt_options
into the binary:)
$(D_CODE $(D_KEYWORD extern) (C) $(D_KEYWORD __gshared) string[] rt_options = [$(D_STRING "gcopt=gc:mygc")];
)
$(DDOC_BLANKLINE )
$(P The standard GC implementation from a statically
linked binary can be removed by redefining the function extern(C) void* register_default_gcs()
.
If no custom garbage collector has been registered
all attempts to allocate GC managed memory will terminate
the application with an appropriate message.)
$(DDOC_BLANKLINE )
$(LNAME2 references, References)
$(DDOC_BLANKLINE )
$(UL $(LI $(LINK2 https://en.wikipedia.org/wiki/Garbage_collection_$(PERCENT )28computer_science$(PERCENT )29, Wikipedia))
$(LI $(LINK2 http://www.iecc.com/gclist/GC-faq.html, GC FAQ))
$(LI $(LINK2 ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps, Uniprocessor Garbage Collector Techniques))
$(LI $(AMAZONLINK 0471941484, Garbage Collection: Algorithms for Automatic Dynamic Memory Management))
)
$(DDOC_BLANKLINE )
$(SPEC_SUBNAV_PREV_NEXT unittest, Unit Tests, float, Floating Point)
)
)