[gclist] Buffy finalizer slayer.

David Chase chase@world.std.com
Fri, 11 Jun 1999 12:55:08 -0400

At 04:35 PM 6/11/99 +0100, Nick Barnes wrote:

>Finalization is much better if you have exact collection and a
>"collect the whole world now" function.  Then the mutator stands a
>better chance of telling that an object has a unique pointer according
>to language semantics.  But exact collection is a somewhat tricky
>notion with optimizing compilers.  With enough information from the
>compiler, you may be able to avoid looking at any registers, stack
>slots, or object slots that contain non-pointers, but it's much harder
>to avoid looking at values (registers and stack slots in particular)
>that contain values which might be no longer in use according to the
>language semantics.

It depends upon how you define "optimizing", of course, but we
(my employer, NaturalBridge) have done this.  The compiler emits
exact maps for all objects and for all points where the GC may
run, and takes into account the liveness information computed
by data flow analysis for registers and stack slots.  Eliot Moss
and Ole Agesen have done the same thing, I believe, for Java bytecodes,
and before that Eliot Moss, Amer Diwan, Rick Hudson, and company
went some distance towards implementing the same thing for Modula-3.

The information is a little bulky; I recall that there was some
discussion of encoding efforts by the Moss/Diwan/Hudson crowd,
and we employ various tricks, and intend to add some more before
we are done.

However, it is absolutely true that this depends on whole-world
collection; a generational collector won't get everything during
a partial collection.  The Big Problem here is that we have seen
(as in, just yesterday, fiddling with a benchmark) a factor of 40
reduction in GC cost going from copy-the-world to generational
collection, which in turn doubled the overall performance of the

David Chase                    --  chase@naturalbridge.com
NaturalBridge LLC              --  http://www.naturalbridge.com
BulletTrain bytecode compiler  --  when you can't wait for performance