[concurrency-interest] Explicitly initializing volatile fields with default values

Aleksey Shipilev aleksey.shipilev at oracle.com
Fri Dec 18 06:59:24 EST 2015


On 12/18/2015 05:11 AM, Justin Sampson wrote:
> Doug Lea wrote:
> 
>> Yes. Without a machine-checkable JLS and JMM formalization, it's
>> hard to prove this definitively. But your account is a more
>> careful version of reasoning we've done before to conclude that
>> there is never any reason to explicitly initialize fields to
>> 0/0.0/false/null. (There might be traces of these discussions in
>> the original JSR133 mail archives.)

Excellent, then we will go forward with pruning stray volatile stores
with default values from JDK:
 https://bugs.openjdk.java.net/browse/JDK-6736490
 https://bugs.openjdk.java.net/browse/JDK-8145680


> This seems like a specific instance of the more general question of
> whether _any_ volatile write has visible memory ordering effects if
> it doesn't actually change the value stored in memory. I remember a
> discussion touching on that question back in January regarding the
> semantics of a failed or no-op compareAndSet. Since the value is not
> changed, there is no way for another thread to notice that anything
> has happened, and therefore no other thread can _depend_ on any such
> memory ordering effects for correctness -- at least in practical
> terms, even if some specific executions happen to be ruled out.

Indeed, this default values case seems to be a special subcase of that
general observation.


> That thread was "Varieties of CAS semantics" here:
> 
> http://cs.oswego.edu/pipermail/concurrency-interest/2015-January/thread.html#13613

Thanks! Good read.

Cheers,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151218/e2d832cc/attachment.bin>


More information about the Concurrency-interest mailing list