[concurrency-interest] DirectByteBuffers and reachabilityFence

Vitaly Davidovich vitalyd at gmail.com
Tue Dec 8 14:00:28 EST 2015


sent from my phone
On Dec 8, 2015 1:54 PM, "Andrew Haley" <aph at redhat.com> wrote:
>
> On 12/08/2015 06:48 PM, Vitaly Davidovich wrote:
> >>
> >> 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.
> >
> > I missed this part.  For concurrent code, how about the fact that
volatile
> > writes in a constructor are effectively treated like final field writes,
> > even though current JMM does not mandate that? Last I heard, a future
JMM
> > revision will make it such that existing behavior is actually spec'd
simply
> > because lots of existing code relies on it and would break, subtly, if
that
> > were to change.
>
> I'm trying to figure out exactly what point you're making.

My point, which you're countering, is that JVM sometimes enforces stricter
semantics than the spec to satisfy behavior that existing code depends on
and doesn't just say "read the spec" to justify breaking changes.

> In what
> sense are volatile writes in a constructor effectively treated like
> final field writes?  From the code I've looked at, volatile writes in
> a constructor are treated exactly like any other kind of volatile
> writes: they're sequentially consistent, and there's nothing stronger
> than that.

Final field prevents subsequent assignment of the newly constructed object
from moving above the final field write inside the constructor; volatile
write doesn't carry this requirement by JMM spec but gets that treatment in
the implementation.

>
> Andrew.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151208/5b1ad168/attachment.html>


More information about the Concurrency-interest mailing list