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 <[email protected]> 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 >> >
