[jmm-dev] ECOOP, JVMLS
david.holmes at oracle.com
Sun Aug 3 22:50:26 UTC 2014
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
> 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.
> 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
>> 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.
More information about the jmm-dev