RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base

[Claes Redestad]

Hi,

initializing volatile fields to their default value has a well-known 
performance penalty, and removing these should typically be safe. This 
patch addresses java.base.

There are however some corner cases that we need to check for, see 
examples and discussion in 
http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014767.html

When meticulously going through and checking each usage for odd pattern 
like this I accidentally did a bit of extra cleanup, mostly addressing a 
number of cases where the volatile field was being read twice. Sorry!

Bug: https://bugs.openjdk.java.net/browse/JDK-8145680

Webrev: http://cr.openjdk.java.net/~redestad/8145680/webrev.01/

It's easy to demonstrate the potential speed-up in microbenchmarks, 
e.g., http://cr.openjdk.java.net/~redestad/8145680/DefaultInitBench.java

Note: when the parent bug was filed back in 2008 there was some internal 
discussion about improving javac and/or the compiler to elide these 
stores. That apparently led nowhere due to difficulty in detecting 
various corner cases, and then the actual cleanup was forgotten. Let's 
not go there this time, shall we?

Thanks!

/Claes