RFR: 8187033: [PPC] Imporve performance of ObjectStreamClass.getClassDataLayout()

Kazunori Ogata OGATAK at jp.ibm.com
Mon Sep 4 05:20:08 UTC 2017

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 mailing list