[concurrency-interest] DirectByteBuffers and reachabilityFence

Andrew Haley aph at redhat.com
Tue Dec 8 04:49:23 EST 2015

On 07/12/15 19:17, Vitaly Davidovich wrote:
>> Correct me if I'm wrong, but basically what you are saying is that hotspot
>> does not perform advanced enough analysis to see that 'this' is actually
>> unnecessary after the call to unsafe.
> In which case? In DBB, `this` is still necessary after the Unsafe call
> since it needs to update position.  In theory, it could move position
> update prior to calling Bits.copyToArray() but it would have to prove that
> it's safe to do so.

That's not at all hard for HotSpot to do.

> Part of that safety check would require it to reason about memory
> effects, side effects, and failure cases (i.e. position update isn't
> reached if there's an exception,

What exception?  HotSpot knows everything about Bits.copyToArray()
because it is inlined.  It knows about all the arguments and
eliminates bounds checks.

> it would need to preserve that effect, also taking into account that
> it may not be able to speculatively write to memory and then undo
> those effects in case of exception).  So the answer is probably
> "yes" to your question above, in a theoretical sense only.

Not at all.

> I think the reasoning here is similar to the above.
> ByteBuffer.get() is invoked on a DBB instance, compiler sees a call
> to Unsafe.getXXX at some point.  The "natural" lifetime of the
> instance survives until the instance method returns. 

No, this is completely wrong.

> So if compiler now wanted to shorten this by observing that `this`
> is unreachable sooner than method exit, it has to prove a bunch of
> things like I mentioned above.

Now inline everything.

Please stop sepeculating about what an optimizer can and can't do.
Please instead concerntrate on the semantics of the language and think
about correctness.


More information about the Concurrency-interest mailing list