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

[Kazunori Ogata]

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.


Regards,
Ogata


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, 
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/

> 
> I'm sure others will tell you that final field semantics only works 
across
> 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 
same 
> 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 
in 
> the other thread before reads that follow it in program order.
> 
> Regards, Peter