Re: JavaMemoryModel: Finalizers

From: Joshua Bloch (joshua.bloch@sun.com)
Date: Mon Apr 07 2003 - 12:37:35 EDT


Bill,

Bill Pugh wrote:

> 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.

What do access controls have to do with it? Suppose *all* access to the
field was via reflection, hence invisible to static analysis. Am I
being dense here? I must be missing something.

>> 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.

Yes, but it violated an underlying principle. I don't see that this
does. Here it looks like we want to support a suspect class of VM
optimizations.

>
> 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.

Sounds fine to me.

>
> Secondly, what about the other ideas I proposed in Saturday's email:

I'm not terribly thrilled with any these. They feel like hacks, and
some have unacceptable limitations (e.g., freeOnceGarbageCollected
presumes you're using some default malloc).

                 Regards,

                 Josh

-------------------------------
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