[concurrency-interest] DirectByteBuffers and reachabilityFence

Andrew Haley aph at redhat.com
Tue Dec 8 11:21:20 EST 2015

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!


More information about the Concurrency-interest mailing list