[Gc] Re: Defeating finalization
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  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.
> 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