[concurrency-interest] DirectByteBuffers and reachabilityFence

Andrew Haley aph at redhat.com
Tue Dec 8 10:17:47 EST 2015


On 12/08/2015 02:40 PM, 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).

Okay.  Can you tell me the relevance of this, though?

> It's not just HotSpot, though: some VMs are even more aggressive, and
> 
> Which java VMs are these? Just curious.

IBM's J9.

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

Or simply determine that nothing depends on position, so an update to
it doesn't have to be generated.

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

Not really: the JMM determines what is possible.  It's not just
"anything".

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

It might already have happened.  The problem with reasoning in such a
fragile way is that things get broken by accident.  The current Unsafe
support works by accident: as we have seen, copyMemory works because
position is updated after the call to Unsafe.  People who are
reasoning in terms of the compiler don't necessarily think of all the
incorrect things library authors might have done.

Andrew.


More information about the Concurrency-interest mailing list