RE: JavaMemoryModel: Another Java threading issue (finalization)

From: Boehm, Hans (
Date: Wed Apr 02 2003 - 13:40:08 EST

Java.lang.ref already provides some facilities along these lines. I don't think this is the right way to solve this problem:

1) If you have prefinalizers and finalizers, you can at most deal with dependency chains of length 2. If you have a dependency chain of length 42 (As finalizer dependends on finalizable B which depends on finalizable C ...), you need finalizers, pre-finalizers, pre-pre-finalizers, ...

2) I don't see how to use it without violating abstraction boundaries. In real life, I may implement class A. I know that its finalizer depends on a class B object, which still needs to be usable when my finalizer runs. B was implemented by someone on a different continent who quit the company 5 years ago. I have no idea whether B uses finalizers. It may not use them directly, but it may refer to something that does. In the scheme I'm advocating, A's constructor simply adds a reference to B to some globally reachable data structure, and A's finalizer removes it. I don't care about B's internals. And I don't care whether A objects will be referenced by finalizable objects. In the "pre-finalizer" approach, I have to understand the whole program to determine whether I should implement a finalizer, a pre-finalizer, a pre-pre-finalizer, or whatever.

3) I would prefer to strengthen the specification of existing constructs to reflect what people thought it was anyway, rather than introduce new constructs.


> -----Original Message-----
> From: Alexander Terekhov []
> Sent: Wednesday, April 02, 2003 12:51 AM
> To:
> Subject: RE: JavaMemoryModel: Another Java threading issue
> (finalization)
> Hans Boehm wrote:
> [...]
> > If objects A and B both have finalizers, A refers to B, and As
> > finalizer needs to access B, there is no way to ensure that A will
> > be finalized first.
> Uhmm, what about the following: introduce post-constructors and pre-
> finalizers and legislate that "pre-" stuff should keep invariants
> intact and "optionally be prepared" for resurrection. The collector
> would ensure two phase processing: the pre-finalizers for all
> collected objects would run first, followed by the finalizers (or
> post-constructors [kinda "resurrectors"] for the resurrected stuff).
> The A's pre-finalizer would then be able to "safely access" B. The
> same would also apply to B's pre-finalizer (if any) WRT A. Well,
> also: < pls see (g) >
> What do you think? TIA.
> regards,
> alexander.
> --
> -------------------------------
> JavaMemoryModel mailing list -
JavaMemoryModel mailing list -

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