[jmm-dev] ECOOP, JVMLS

[David Holmes]

On 4/08/2014 2:39 AM, Jeremy Manson wrote:
> I brought finalization up with Aleksey at the summit.  I have another idea.
>
>
> I assert that not providing stronger guarantees for finalization buys us
> approximately nothing.  A quick scan of a large code base suggests that
> only 1/10K classes have finalizers.  Optimizing something that rare is
> deeply unlikely to buy us any performance in practice.  On the flip side,
> to provide a meaningful guarantee, all we need to do is add a bunch of
> checks in the compiler that prevent making certain optimization choices
> when an object is finalizable.

But presumably the key here is to optimize the "is this object 
finalizable" check?

> Furthermore, this is one of the rare cases in the model for which the weird
> behavior comes up all the time in practice: I get questions from people who
> run into this behavior several times a year.
>
> Furthermore, keepAlive() is going to confuse people.  When people actually
> remember to use it, it will make code less readable, and will likely simply
> be sprinkled throughout the code in the same way that people add volatile:
> as a mystic incantation that removes weird behavior.  It's going to need to
> be average users - the consumers of a library - who need to use it, and
> they will invariably need to run into this problem and debug it before they
> know they have to use it.
>
> Instead of all of this, let's just make the strong guarantee that if an
> object is transitively reachable from a local variable that is currently in
> scope (according to the bytecode's LVT), then the end of that scope happens
> before the execution of the finalizer.  Maybe we need to make certain
> guarantees about other GC roots, too (although I'm not sure exactly which -
> it seems as if the class unloading semantics take care of most of them).
>   Then we forget about this topic forever.

I think getting rid of the possibility that an object can be gc'd and 
finalized whilst a thread is in the middle of executing a method on that 
object would be good thing.

I'm not sure what you just expressed about the scope is appropriate 
though. If you explicitly null a local and invoke GC you should expect 
to be able to trigger finalization of that instance.

David
-----

> Jeremy
>
>
> On Sun, Aug 3, 2014 at 5:48 AM, Aleksey Shipilev <
> aleksey.shipilev at oracle.com> wrote:
>
>> On 08/03/2014 05:36 AM, Doug Lea wrote:
>>> * Someone (other than Hans!) reminded me that something like the
>>> reachabilityFence included in the never-shipped Fences API
>>> (
>> http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/Fences.html
>> )
>>
>> Yes, and I forgot to mention this use case highlighted to us at JVMLS.
>>
>> Basically, have a Java class which points to naked memory addresses
>> (think DirectByteBuffer-like implementation). Your method takes that
>> Java instance as the method argument, pulls the native memory address
>> from its field and starts working with it. At some later point during
>> the execution of that method, you hit safepoint, and VM figures the
>> enclosing instance is not needed anymore (e.g. dataflow suggests no uses
>> for that local in future) -- which arguably lets VM to run the cleanup
>> mechanics, freeing up the referenced memory. VM resumes from GC,
>> continues in the same method, boom, use-after-free.
>>
>> Thanks,
>> -Aleksey.
>>
>>
>>