At 9:19 PM -0700 4/6/03, Joshua Bloch wrote:
>>
>>
>>While the this$0 field of the FinalizerGuardian class will be read,
>>the finalizerGuardian field of class Foo will never be read, the
>>JVM should be free to run the finalizer immediately.
>
>What about reflection?
Not all security managers allow reflective access that violations
access controls.
>This contradicts peoples instincts, and will cause all manner of errors.
A lot of people's instincts say that Double Checked Locking works,
but that didn't stop us from deciding to not support it.
>
>Maybe this is too harsh. Maybe we need a rule that liveness
>optimizations can only apply to methods variables, and that any
>object reachable via a field of a reachable object is itself
>reachable.
>
>Amen, brother.
>
As we've found in a number of instances, the appropriate semantics
are those that leaves both the programmers and VM implementors
grumbling, but neither screaming.
Let's propose we amend JLS 12.6.1 to state clearly that any object
that is referenced from a field or element of a reachable object is
reachable.
Do any of the VM implementors want to scream?
Secondly, what about the other ideas I proposed in Saturday's email:
* the keepAlive method
* rule on locks keeping objects reachable
* freeOnceGarbageCollected
* runOnceGarbageCollected
-------------------------------
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