GC statistics (was Re: big project ported)

Wed Oct 27 17:12:00 GMT 1999

On 1999年10月27日, Kresten Krab Thorup wrote:
>>These performance issues to be expected from a conservative collector,
>such as the boehm system. An exact collector, which knows exactly
>which registers and memory locations are pointers to objects, can do a
>much better job because it only needs to scan live objects. A
>conservative collector on the other hand needs to visit all objects in
>every gc cycle -- both the ones that are live and the ones that are
>garbage. Experiments show that most objects turn out to be garbage
>after a single gc-cycle, so the problem is inevitable.
>
This is just plain not true. I've written real-time embedded conservative
GCs for C++ systems. Like precise collectors, they start tracing from the
roots and only visit live objects. By definition, they do not visit garbage
objects because, if they did, the objects would not be garbage.
Actual timing of GC shows collecting a heap full of garbage but with
very few live objects takes very little time. The only time related to the
total size of the heap is the sweep phase, but that typically allocates
1 bit per object, so 32 objects can be freed with a single word write.
The advantage of conservative collectors is their low bookkeeping overhead
and compatiblity with C/C++. Collectors I've designed typically require 4%
of the total heap size for bookkeeping which includes block maps and allocation
maps on the front of the heap. The largest overhead tends to be discretization
overhead, since allocators can never allocate exactly the amount of bytes
requested by the application.
--
Jon Olson, Modular Mining Systems
	 3289 E. Hemisphere Loop
	 Tucson, AZ 85706
olson@mmsi.com
Phone:	(520)746-9127
Fax:	(520)889-5790