[concurrency-interest] DirectByteBuffers and reachabilityFence

Vitaly Davidovich vitalyd at gmail.com
Tue Dec 8 11:44:53 EST 2015


>
> I don't think it's generally true.


So your claim is that, generally speaking, if something works a certain
(observable) way in interpreter it's not guaranteed to work in same
(observable) way with compiled code, except quicker? I find that hard to
believe based on various compiler-dev threads I've read over the years, but
no point in debating this.

And in that case the answer is, I suspect, that the optimizer doesn't
> know that the position field is unused by the finalizer.  If it did
> know this, then you'd have early finalization.  As for the other
> cases, it's not worth speculating without looking at code.


The question is why do the various getters work in the face of early
finalization/reclaim given they don't touch internal state? I don't have a
good answer for this other than compiler is careful about optimizing around
Unsafe operations (it does know about unsafe memory accesses, that I know
for sure).

Me too.  But surely why it works isn't really all that interesting:
> what is much more interesting, and relevant to this list, is that it
> may stop working, may already not work, or may not work in some VMs.


Whether why it works today is interesting or not is subjective.  Whether
it's relevant to this list -- is this a theory only list? I don't think
so.  Theoretical discussions are good and form a basis for implementation,
but implementation details are also interesting (and have material
performance implications), at least to me.

I don't see why: it'd require a patch to DBB, but people don't ship
> JVMs without a copy of rt.jar (or somesuch) anyway.


See my comment about final field treatment as it stands today.  You can
patch JDK, but you'll likely break some user code that was "following" DBB
as a model.  Personally, I prefer aggressive optimizations and willing to
fix code if I did something wrong, but in this case there was no good way
to fix the code prior to writing it.  This is not a spec-wise
decision/situation, this is purely practical implications of breaking user
code.  This whole thing begs the rhetorical question then -- why was this
functionality released given it's rife with lifetime issues? That ship has
sailed now, and I'd hate to be the one explaining to users that some
optimizer change now segfaults their VM.

We have very different hunches!


Looks like it; let's circle back to this thread if/when an
optimization/code change breaks user code, which works today, of this
nature -- I'll be ready with the popcorn. :)


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

> On 12/08/2015 03:35 PM, Vitaly Davidovich wrote:
> >>
> >> Okay.  Can you tell me the relevance of this, though?
> >
> > Relevance is if code works correctly in interpreter then, practically
> > speaking, compiler tries to not break it.  Of course this isn't always
> the
> > case (e.g. compiler hoisting reads of a non-volatile field that should be
> > volatile), but is generally true.
>
> I don't think it's generally true.
>
> >> 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.
> >
> > There are other operations in DBB that touch native memory that
> > appear to work without any position update (i.e. the various
> > getters).  Again, I'm not advocating reasoning like this for new
> > code that someone may write.  The thread started with Alexandre
> > asking a question for which he then added a segfaulting example; we
> > tried to figure out why his didn't work and DBB works.
>
> And in that case the answer is, I suspect, that the optimizer doesn't
> know that the position field is unused by the finalizer.  If it did
> know this, then you'd have early finalization.  As for the other
> cases, it's not worth speculating without looking at code.
>
> > By definition, this is speculation unless you're expecting me to
> > provide a full trace through the compiler optimization pipeline.  At
> > no point did I advise/suggest that someone should reason like this
> > for their code, I was merely trying to use educated guesses as to
> > why it works keeping compiler optimizations in mind.
>
> Me too.  But surely why it works isn't really all that interesting:
> what is much more interesting, and relevant to this list, is that it
> may stop working, may already not work, or may not work in some VMs.
>
> > As to the theoretical vs practical aspect, I agree that there's
> > nothing holding this together spec/theory wise; afterall, I'm quite
> > happy that reachabilityFence is being added (don't particularly like
> > that name, but whatever).  But if you create a spec conforming JVM
> > implementation today that segfaults in DBB, congrats but nobody is
> > going to use it.
>
> I don't see why: it'd require a patch to DBB, but people don't ship
> JVMs without a copy of rt.jar (or somesuch) anyway.
>
> > Moreover, once reachabilityFence is added and sprinkled in all the
> > appropriate JDK places, there may be a time when someone advertently
> > or inadvertently makes a compiler optimization that will break
> > DBB-like clones in user code.  My hunch, given the mindset of java
> > and emphasis on not breaking code, even code that's misbehaved and
> > not conforming to spec, is that such optimization will not go
> > forward.
>
> We have very different hunches!
>
> Andrew.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151208/5c90d071/attachment.html>


More information about the Concurrency-interest mailing list