[Gc] Re: Defeating finalization

Ludovic Courtès ludovic.courtes at laas.fr
Tue May 2 01:55:50 PDT 2006


Hans Boehm <Hans.Boehm at hp.com> writes:

> It always waits for another cycle to collect the object.  However, I
> should have mentioned that you do need to set GC_java_finalization to make
> sure that objects reachable from the finalizer are traced after
> finalizability is determined.  If you use the normal topologically-ordered
> finalization mechanism, that's not necesary, since such objects are
> already traced while determining finalizability.

Ok, thanks for the clarification.  Perhaps we should be added to the

> It's correct in the sense that if you have an absolutely single-threaded
> executable, and don't remove objects from guardians while you might still
> need the external object state, you should be safe.  In my mind, the
> problems with this are:
> 1) That's not a very convenient programming model.  If a library
> introduces a guardian, you need to occasionally make explicit calls back
> into the library just in case something needs to be cleaned up, even if
> you don't otherwise need it anymore.  Finalization really wants threads.

In Guile, for instance, one can register a hook that will get called
after any "stop-the-world" GC cycle.  The manual [0] documents it as an
appropriate place to invoke guardians.  This leads to an event-driven
model that can be suitable for a single-threaded program.

[0] https://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/GC-Hooks.html#GC-Hooks

> 2) Many interesting programs are already multithreaded, especially on
> Windowsi, where it seems to be the vast majority.  And we expect
> that to become more so shortly.


Thanks for your help,

More information about the Gc mailing list