I think we fundamentally agree, but I mostly misunderstood your first message.
Ideally, finalization should be based on a notion of liveness that's easy to explain in terms of the simplest possible semantics of the language. The garbage collector should be allowed to reclaim blocks early, so long as it doesn't affect finalization semantics.
In practice, defining when an object is eligible for finalization in this way seems to run into several difficulties:
1) It wasn't the decision originally made in the JLS.
2) It is likely to involve a substantial performance hit that people aren't willing to take for a rarely used feature.
3) It doesn't interact well with the memory model, which already trades off some simplicity for performance (a decision that I believe is basically dictated by current hardware constraints.)
Hence, I've been advocating a fairly minimal change to the current semantics, which admittedly leaves many currently broken programs involving finalizers broken. But it makes it possible to write correct programs involving finalizers. And it makes some existing programs correct. And it breaks no currently correct programs (a somewhat vacuous statement, since there are probably no currently correct programs involving finalizers).
Hans
> -----Original Message-----
> From: BART JACOBS [mailto:bart.jacobs@student.kuleuven.ac.be]
> Sent: Thursday, April 10, 2003 3:07 PM
> To: Hans.Boehm@hp.com
> Cc: JavaMemoryModel@cs.umd.edu
> Subject: Re: JavaMemoryModel: A problematical case for finalizers
>
>
> Thank you for your response after my rather uncivilised message.
>
> > But there are occasional cases in which some non-memory
> resource needs to
> > be reclaimed when a memory block X becomes unreachable, and
> there is no
> > easy other way to determine when that is.
>
> Is it not true that when you say this, you are assuming that
> (memory block X
> becoming unreachable) coincides with ((some object that
> encapsulates the non-
> memory resource) becoming (dead (i.e. no longer live)))?
> Because, and correct
> me if I'm wrong, the basic rationale for finalizers is that an object
> encapsulates a native resource, so that the native resource
> can only be used
> through method invocations whose target is the object, and as
> a result, when
> the object is no longer live, the native resource can be
> cleaned up. By an
> object being live, I mean that the last method invocation
> whose target is the
> object has not yet completed. (This, of course, being a
> dynamic and generally
> undecidable property.)
>
> The point of my previous message was that _in principle_ (and
> this is a
> qualification I erroneously omitted in my previous message)
> there need not be
> a correspondence between the concept of liveness of an object
> and the concept
> of reachability of a memory block. Any such correspondence
> depends on the
> implementation of the virtual machine. Many examples of
> reasons why such
> correspondence can be absent have been presented on this mailing list.
>
> The important thing about liveness of an object is that it
> makes sense at the
> abstract Java semantics level.
>
> As a virtual machine designer, one could choose to establish
> a correspondence
> between liveness of an object and reachability of a memory
> block, although
> this would exclude a number of desirable implementation techniques.
>
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:44 EDT