Alan Bateman <alan.bate...@oracle.com> wrote on 2017/06/27 16:01:25: > From: Alan Bateman <alan.bate...@oracle.com> > To: "Langer, Christoph" <christoph.lan...@sap.com>, Kazunori Ogata > <oga...@jp.ibm.com>, core-libs-dev <core-libs-dev@openjdk.java.net>, "nio- > d...@openjdk.java.net" <nio-...@openjdk.java.net> > Cc: "ppc-aix-port-...@openjdk.java.net" <ppc-aix-port-...@openjdk.java.net> > Date: 2017/06/27 16:01 > Subject: Re: 8179527: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > On 27/06/2017 07:50, Langer, Christoph wrote: > > Hi Ogata, > > > > I'm redirecting this RFR to core-libs-dev and nio-dev as it potentially > affects all platforms and should be discussed there. > > > > As for your proposal: I can generally understand that using volatile at > this place hurts performance on the power platform and this should be > improved. I however don't fully oversee if just removing the volatile > qualifier is the only thing to do here. Maybe one should implement some > double checked locking pattern around the static field bugLevel and its > initialization from system properties? I guess during VM initialization > multiple threads can got to this place and the volatile qualifier was > added for synchronizing access to "bugLevel". > > > It could be changed to be a final field in a holder class.
The code looks that it doesn't use final intentionally because it postpones setting set bugLevel until VM.isBooted() returns true, though I'm not sure if the value of privilegedGetProperty() can change during a bootstrap of JVM. ----- 289: if (!VM.isBooted()) 290: return false; ----- > It might be > better if we can just remove the test from Charset.checkName as I think > that dates back to an incompatible change going from JDK 1.4 to JDK 5 > that should no longer be a concern. > > -Alan >
