RE: JavaMemoryModel: Finalization idioms

From: Boehm, Hans (
Date: Mon May 02 2005 - 20:37:17 EDT

> From: David > Detlefs - Sun Microsystems Labs BOS
> Sent: Sunday, May 01, 2005 6:52 PM
> You weren't too explicit here, but I'm going to assume that
> you're referring to the idea that with Finalizers, everything
> (detection of unreachability, placement on a queue, actual
> execution of finalize
> methods) is done by the system, in system threads, and
> finalizers must therefore be considered concurrent with
> mutator code, leading the problems that Hans is discussion.
> With weak references, the argument goes, you can have the
> weak refs to the unreachable objects placed on a queue, and
> then process the queue explicitly (executing the moral
> equivalent of finalizers) at well known program points that
> avoid these race conditions.
> I find this argument a little suspect. Maybe it works for
> simple single-threaded programs. In doing weak reference
> processing explicitly, you have two dangers:
> 1) you won't process the queue often enough, allowing it to grow and
> increase your memory requirements beyond what they ideally ought
> to do.
> 2) in avoiding (1), you'll sprinkle your code too liberally with
> calls to a "process_weak_refs_if_necessary", futzing up the code
> and perhaps slowing it down.
Do you even get that far? If I'm implementing
a library, which requires finalization, I don't really have anyplace
to sprinkle the "process_weak_refs_if_necessary" calls. I presumably
solve this problem by having the library create a thread which
performs those calls. This puts me back in the same position as
with finalizers: I've introduced concurrency, where there might
not have been any before.

I do think that java.lang.ref makes some things easier. They
kind of give you ordered finalization in a way that encourages
the programmer to avoid cycles and unnecessary long chains.
And if we had a single-threaded language, they might be the best
you can do. But I don't think they address the problems we were


JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:10 EDT