[concurrency-interest] DirectByteBuffers and reachabilityFence

Vitaly Davidovich vitalyd at gmail.com
Tue Dec 8 09:40:57 EST 2015


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


On Tue, Dec 8, 2015 at 9:33 AM, Andrew Haley <aph at redhat.com> wrote:

> On 12/08/2015 12:07 PM, Vitaly Davidovich wrote:
> >>> 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.
>
> > Same here
>
> 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.
>
> > It's speculation based on observing a real compiler and looking at
> > its code generation in various scenarios.  The bottom line is that
> > it plays conservative a lot of the time, and that is the sentiment
> > I've picked up from various conversations on the compiler list over
> > the years.  Yes, it's speculation and a Sufficiently Smart Compiler
> > can do things differently.
>
> It's not just HotSpot, though: some VMs are even more aggressive, and
> we have seen finalizers executed even before constructors have
> completed.  And that is allowed by the specification.
>
> > But keep in mind if hotspot started scheduling operations more
> > aggressively around Unsafe usage a lot of code would break
>
> It's already broken.
>
> Andrew.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151208/a5a357f9/attachment-0001.html>


More information about the Concurrency-interest mailing list