Just to clarify:
I'm proposing two changes:
1) Synchronization ==> reachable
2) Referenced by reachable through volatile or final ==> reachable
Even if we strengthen (2) as David suggests, I think (1) is still necessary, since the compiler will always be able to optimize away nonvolatile field references and eliminate resulting dead pointers. I believe that prohibiting this would involve a significant performance hit.
I think (1) is necessary for finalization to be usable at all. And most methods on finalizable objects will need to be synchronized. It would be nice if that could be avoided, but finalization should be rare enough that I think we can live with it. I don't know of alternatives that are usable and correct. And the correct usage rules with (1) are simple though, as you say, draconian. (I suspect most current uses of finalization are broken under this rule, but less so than under current rules. And they become fixable. Fundamentally finalizers introduce concurrency. Hence you need synchronization.)
I've needed (2) only to support some idioms involving more sophisticated uses of finalization. And in those cases the data structures keeping the object reachable are built explicitly for the purpose. Hence requiring "volatile" or "final" is not so bad. (In the "finalizer guardian" example, the reference is naturally final. For finalizer ordering you would need a container built for the purpose with volatile fields.)
Hans
> -----Original Message-----
> From: David Holmes [mailto:dholmes@dltech.com.au]
> Sent: Tuesday, April 01, 2003 2:45 PM
> To: Boehm, Hans
> Cc: javamemorymodel@cs.umd.edu
> Subject: RE: JavaMemoryModel: Another Java threading issue
> (finalization)
>
>
> Hans Boehm wrote:
> > My argument for limiting it to volatile and final:
> >
> > 1) It's less likely to interfere with optimization. Optimizing
> >
> > 2) It's in some sense a smaller change to the spec.
> >
> > 3) It means something to say than an object is reachable up to a
> > certain assignment to a volatile field
>
> My arguments against:
>
> 1. Unless all the references in the chain are volatile/final then the
> problem remains. Taking this to an extreme all references become
> volatile or final just incase a referenced object would be deemed
> unreachable. It's probably not as bad as this as the problems only
> occur when finalizers exist, but I'm cautious about adding yet another
> subtlety to an already overly-subtle situation.
>
> 2. It doesn't help with the simple case of the last use of an object
> with a finalizer - such as one that allocates native memory and free's
> it in the finalizer (which is one of the suggested uses for
> finalizers). Using synchronization would "fix" this, but as you can't
> tell when the last use occurs you'll have to synchronize all the time.
> [Maybe the standard idiom for finalizers should be that they can only
> be defined for classes that employ synchronized methods - but that
> seems rather draconian.]
>
> 3. I think applying it to all references is an even smaller change to
> the spec, because it clarifies what I believe is already the intent.
>
> I get very uncomfortable with these ultra-subtle semantics that give
> the impression to the programmer that the compiler/VM writer is out to
> get them. ;-)
>
> Cheers,
> David Holmes
>
-------------------------------
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