RFR: 8187033: [PPC] Imporve performance of ObjectStreamClass.getClassDataLayout()
peter.levart at gmail.com
Mon Sep 4 09:07:37 UTC 2017
Maybe a more knowledgeable soul could shed some light into an internal
It was meant to be used internally in the java.lang.invoke package, but
in JDK 9 it was made public, not exported, so it can be used in the
entire java.base module. There are already some usages in java.util
package and recently, sun.nio.cs.StandardCharsets added a usage in JDK
10. When @Stable annotation was designed it was debated whether @Stable
instance fields should get the treatment of final instance fields as far
as JMM is concerned. So the question is, was this suggestion actually
implemented in the VM. Scanning the usages in JDK 10, I can see that all
@Stable instance fields of array type(s) are also marked with final
modifier. Except one:
Is this an oversight or a consequence of @Stable implying the memory
order semantics of final?
If it is the later, then perhaps Ogata could simply put @Stable in front
of dataLayout field.
On 09/04/2017 07:20 AM, Kazunori Ogata wrote:
> Hi Aleksey and Hans,
> I implemented four variations of changes and measured performance
> 1) Put VarHandle.fullFence() between initialization of ClassDataSlot and
> writing the reference to non-volatile dataLayout.
> Webrev: http://cr.openjdk.java.net/~horii/8187033/webrev.01-fence/
> 2) Use Unsafe.getObjectAcquire() and Unsafe.putObjectRelease() for
> reading/writing dataLayout.
> Webrev: http://cr.openjdk.java.net/~horii/8187033/webrev.01-unsafe/
> 3) Put reference to ClassDataSlot into a final field of an object and
> store the object to non-volatile dataLayout. Every invocation of
> getDataLayout() reads the final field needs to deference the object
> Webrev: http://cr.openjdk.java.net/~horii/8187033/webrev.01-final/
> 4) Put reference to ClassDataSlot into a final field of an object, read
> the final field immediately after the object creation, and store it to
> non-volatile dataLayout. I think this is also correct based on the
> semantics of final fields and data dependency.
> Webrev: http://cr.openjdk.java.net/~horii/8187033/webrev.01-final2/
> The performance improvements were:
> 1) +3.5%
> 2) +1.1%
> 3) +2.2%
> 4) +3.4%
> The reason of small improvement in 2) is that the actual code of
> Unsafe.getObjectAcquire()/putObjectRelease() simply invokes
> getObjectVolatile()/putObjectVolatile() in them, respectively.
> If all implementations are correct, I'd like to take 4) because I want to
> back port this change to jdk8u but VarHandle is only available in jdk9 or
More information about the core-libs-dev