At 03:28 PM 4/1/2003, Boehm, Hans wrote:
>Just to clarify:
>
>I'm proposing two changes:
>
>1) Synchronization ==> reachable
>
>2) Referenced by reachable through volatile or final ==> reachable
This is a minor tweak. I would add array references too.
volatile X[] aX = ...;
There is no way to make the array elements themselves volatile, so without
special casing arrays you couldn't use them to keep things 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
-------------------------------
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