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.
Hans
> -----Original Message-----
> From: Alexander Terekhov [mailto:TEREKHOV@de.ibm.com]
> Sent: Wednesday, April 02, 2003 12:51 AM
> To: javamemorymodel@cs.umd.edu
> 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) >
>
> http://www.cs.umd.edu/~pugh/java/memoryModel/archive/1038.html
>
> What do you think? TIA.
>
> regards,
> alexander.
>
> --
> http://www.google.com/groups?selm=3D23534C.681063DC%40web.de
>
> -------------------------------
> JavaMemoryModel mailing list -
> http://www.cs.umd.edu/~pugh/java/memoryModel
>
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:43 EDT