Claes, For the cases where boolean was being assigned to 'true' (ASSCI and FileLockImpl) does it hurt performance since the accessor methods will now include a branch at the bytecode level? See: "Speed-kings of inverting booleans" at http://www.javaspecialists.eu/archive/Issue042.html
Jason ________________________________________ From: core-libs-dev <core-libs-dev-boun...@openjdk.java.net> on behalf of Claes Redestad <claes.redes...@oracle.com> Sent: Sunday, December 20, 2015 11:29 AM To: core-libs-dev@openjdk.java.net Subject: Re: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base 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 >
