[concurrency-interest] DirectByteBuffers and reachabilityFence

Vitaly Davidovich vitalyd at gmail.com
Tue Dec 8 10:38:09 EST 2015


>
> If you're talking about simply observing the effects of an object being
> collected while method invocations on that object are still in flight, see
> this article:
> http://www.infoq.com/articles/Fatal-Flaw-Finalizers-Phantoms
> We have run into this issue numerous times in various situations, which is
> why we're happy to see reachabilityFence() come into being.  So yes, it's
> already broken.


Nope, I'm talking about breaking existing DBB code as it stands today.
Alexandre already posted an example of where similar but subtly different
(with respect to DBB) code breaks, so I'm well aware it's a problem.

On Tue, Dec 8, 2015 at 10:22 AM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> On 12/08/2015 08:40 AM, Vitaly Davidovich wrote:
>
>>     The lifetime, natural or otherwise, of an instance does not survive
>>     until an instance method returns because, a lot of the time, that
>>     instance method is inlined.
>>
>>
>> You're talking about optimization here (inlining); by "natural" I meant
>> the naive/no optimization case (e.g. interpreter, debugger attached
>> w/breakpoint in method, etc).
>>
>>     It's not just HotSpot, though: some VMs are even more aggressive, and
>>
>> Which java VMs are these? Just curious.
>>
>>     we have seen finalizers executed even before constructors have
>>     completed.  And that is allowed by the specification.
>>
>>
>> Ok, but that's beside the point, really.  Surely if compiler can
>> optimize and arrange for liveness to allow for it, then it's a good
>> thing it does that.  My point isn't that this cannot happen due to spec,
>> but rather that in places like DBB where `this` is used after the Unsafe
>> call the  compiler has to schedule things differently in order to reduce
>> lifetime.  And my point is that compilers generally tend to be cautious
>> in doing things that may break code.  This is the practical aspect we
>> were referring to - it's actual humans writing these optimizations, and
>> they're sensitive to breaking code, particularly in java.
>> Theoretically, yes, anything is possible.
>>
>>     It's already broken.
>>
>>
>> Sure.  Now try to submit a patch to Hotspot that will break this case,
>> even if allowed by spec, and see how far you get :).
>>
>
> If you're talking about simply observing the effects of an object being
> collected while method invocations on that object are still in flight, see
> this article:
>
> http://www.infoq.com/articles/Fatal-Flaw-Finalizers-Phantoms
>
> We have run into this issue numerous times in various situations, which is
> why we're happy to see reachabilityFence() come into being.  So yes, it's
> already broken.
> --
> - DML
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151208/9cf056d8/attachment-0001.html>


More information about the Concurrency-interest mailing list