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