[gclist] Finalizers & Reference counting.

[Boehm, Hans]

> -----Original Message-----
> From: Nick Barnes [mailto:Nick.Barnes@pobox.com]
> It's pretty obvious that the ability to relocate objects so that live
> objects are adjacent (or even so that topologically close objects are
> close in the address space) is potentially good for the performance of
> the memory hierarchy.  The basic argument says that without
> collection, fragmentation means that accesses are all over the map,
> but with collection, to-space fits into L2 (say).
I think this is controversial and application dependent.  Good nonmoving GCs don't do too bad a job at keeping live objects together.  In most cases, our collector, for example, will often reclaim entire pages of small unreachable objects, and resuse the page in its entirety.  We benefit greatly from the fact that real program behavior isn't random.  Copying has the major disadvantage that you need to touch at least twice the live memory being traced.  For a generational collector that's often worth it, but ...
> 
> Then people largely lost interest in copying GC (because the focus of
> GC moved to C++, in which moving GC is impossible, and Java, in which
> it was very difficult).  With non-moving GC, the arguments each way
> are harder (as Hans states).
Early Sun JVMs compacted in-place.  This may be a reasonable choice in a memory-limited environment.  I think the IBM VMs still use a similar strategy, with much more competitive time performance, though they compact only rarely, and no longer at every collection.

The tradeoffs are nontrivial.  See http://researchweb.watson.ibm.com/people/d/dfb/papers/Attanasio01Comparative.pdf for example.

Hans