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

[Ulf]

Hi Claes,

I had a very short look and found in j.l.Thread:
  211      * Java thread status for tools, 0 indicate thread 'not yet started'
I guess you meant:
  211      * Java thread status for tools; 0 indicates: thread 'not yet started'.

-Ulf


Am 20.12.2015 um 18:29 schrieb Claes Redestad:
> Hi,
>
> the changes to java.net.URI stood out as a bit too intrusive for a cleanup like this, and there's 
> precious little measurable benefit. I decided to break out those to a separate RFE and simplified 
> this patch:
>
> Webrev: http://cr.openjdk.java.net/~redestad/8145680/webrev.02
>
> /Claes
>
> On 2015-12-19 14:07, Claes Redestad wrote:
>> 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
>>
>
>