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

Kazunori Ogata OGATAK at jp.ibm.com
Mon Sep 4 08:23:29 UTC 2017

Hi Peter,

Thank you for your comment.  I thought the compiler must insert memory 
fence at the end of object initializer, but I agree relying on it is not 
correct w.r.t. JMM.

Then I'll take 1) 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/), as 
it achieved the best performance.


Peter Levart <peter.levart at gmail.com> wrote on 2017/09/04 17:06:21:

> From: Peter Levart <peter.levart at gmail.com>
> To: Kazunori Ogata <OGATAK at jp.ibm.com>, core-libs-dev <core-libs-
> dev at openjdk.java.net>, Aleksey Shipilev <shade at redhat.com>, Hans Boehm 
> <hboehm at google.com>
> Date: 2017/09/04 17:06
> Subject: Re: RFR: 8187033: [PPC] Imporve performance of 
> ObjectStreamClass.getClassDataLayout()
> Hi Ogata,

> On 09/04/2017 07:20 AM, Kazunori Ogata wrote:
> 4) Put reference to ClassDataSlot[] into a final field of an object, 
> 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/

> I'm sure others will tell you that final field semantics only works 
> threads when you also read the final field in the other thread from the 
> thread that writes to it. Storing and reading the final field in the 
> thread won't help order the write to a non final field after writes that 

> precede it in program order nor to order the read of a non-final field 
> the other thread before reads that follow it in program order.
> Regards, Peter

More information about the core-libs-dev mailing list