[concurrency-interest] Volatile stores in constructors, disallowed to see the default value

David Holmes davidcholmes at aapt.net.au
Wed Nov 27 17:51:25 EST 2013


Doug writes:
> On 11/27/2013 02:06 PM, Vitaly Davidovich wrote:
> > But either
> > way, optimizations to avoid zeroing memory is an implementation
> detail and thus
> > cannot be relied upon from JMM standpoint, which I think you're saying.
> >
> > The other issue is that even if we determine that volatiles
> don't get this
> > treatment, if JVM is already ensuring it, it's not going to be
> practical to
> > change it and risk hard to debug problems creeping in.  May as
> > well update the spec now ...
>
> Right. To summarize:
>
> * Programmers do not expect that even though final fields are specifically
> publication-safe, volatile fields are not always so.

Programmers don't grok "unsafe publication" - full stop! Once it is
explained to them they have no reason to assume v0latile fields are special
because only final fields are called out as such.

> * For various implementation reasons, JVMs arrange that
> volatile fields are publication safe anyway, at least in
> cases we know about.

I think not - that is how this whole debate reignited due to a proposed
change from the PPC64 folk to add the constructor barrier for volatiles (but
that was in a misguided attempt to pass the jcstress tests that assumed the
barrier was required).

> * Actually updating the JMM/JLS to mandate this is not easy
> (no small tweak that I know applies). But now is a good time
> to be considering a full revision for JDK9.

I agree with that :)

David
-----

> * In the mean time, it would make sense to further test
> and validate JVMs as meeting this likely future spec.
>
> -Doug
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



More information about the Concurrency-interest mailing list