[concurrency-interest] DirectByteBuffers and reachabilityFence

Andrew Haley aph at redhat.com
Tue Dec 8 13:15:21 EST 2015

On 12/08/2015 04:44 PM, Vitaly Davidovich wrote:

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

Yes, that is my claim.  It's certainly true in the case of concurrent
code, which is the subject of this list.  It's certainly true in the
case of reachability, which is the subject we're discussing.

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

Dunno.  It'd be interesting to try to break a getter and then look at
the code.

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

This warning about object lifetimes and finalizers is part of the
now-twenty-year-old Java Language Specification.  One would hope that
people have had time to get used to it and its implications.

> That ship has sailed now, and I'd hate to be the one explaining to
> users that some optimizer change now segfaults their VM.

It'll only happen with some user abusing Unsafe.  I know perfectly
well what would be said!


More information about the Concurrency-interest mailing list