8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel()
OGATAK at jp.ibm.com
Tue Jun 27 08:34:46 UTC 2017
Alan Bateman <Alan.Bateman at oracle.com> wrote on 2017/06/27 16:01:25:
> From: Alan Bateman <Alan.Bateman at oracle.com>
> To: "Langer, Christoph" <christoph.langer at sap.com>, Kazunori Ogata
> <OGATAK at jp.ibm.com>, core-libs-dev <core-libs-dev at openjdk.java.net>,
> dev at openjdk.java.net" <nio-dev at openjdk.java.net>
> Cc: "ppc-aix-port-dev at openjdk.java.net"
<ppc-aix-port-dev at openjdk.java.net>
> Date: 2017/06/27 16:01
> Subject: Re: 8179527: Ineffective use of volatile hurts performance of
> 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
> affects all platforms and should be discussed there.
> > As for your proposal: I can generally understand that using volatile
> 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.
More information about the core-libs-dev