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

[Joel Borggrén-Franck]

Hi Claes,

src/java.base/share/classes/java/lang/reflect/Parameter.java
src/java.base/share/classes/sun/reflect/MethodAccessorGenerator.java
src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java

looks fine to me.

src/java.base/share/classes/java/lang/Class.java

is fine to but isn't

enumConstants = constants = temporatyConstants;

slightly more idiomatic than

-                enumConstants = temporaryConstants;
+                constants = temporaryConstants;
+                enumConstants = constants;

cheers
/Joel



On Sun, Dec 20, 2015 at 6:29 PM, Claes Redestad
<claes.redestad at oracle.com> wrote:
> 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
>>
>