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
