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

Vitaly Davidovich vitalyd at gmail.com
Wed Nov 27 14:06:06 EST 2013


Why do volatile fields need explicit pre zeroing (with a fence) while
normal fields don't then? Also, I think JVM can only avoid pre zeroing if
it can prove that subsequent code overwrites the value before anything can
be observed.  It definitely tries to do this for array allocations; if it
didn't pre zero who's going to ensure that unset slots are actually
zero/default if read? 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 ...

Sent from my phone
On Nov 27, 2013 1:41 PM, "Doug Lea" <dl at cs.oswego.edu> wrote:

> On 11/27/2013 09:06 AM, Vitaly Davidovich wrote:
>
>  But the issue is whether assignment of the new C instance to some other
>> memory
>> must occur after the volatile stores.
>>
>
> Sorry for mis-remembering why I had treated this issue as basically
> settled:
> Unless a JVM always pre-zeros memory (which usually not a good option),
> then
> even if not explicitly initialized, volatile fields must be zeroed
> in the constructor body, with a release fence before publication.
> And so even though there are cases in which the JMM does not
> strictly require mechanics preventing publication reordering
> in constructors of classes with volatile fields, the only good
> implementation choices for JVMs are either to use non-volatile writes
> with a trailing release fence, or to perform each volatile write
> with full fencing. Either way, there is no reordering with publication.
> Unfortunately, programmers cannot rely on a spec to guarantee
> it, at least until the JMM is revised.
>
> -Doug
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20131127/08a39366/attachment.html>


More information about the Concurrency-interest mailing list