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

Kazunori Ogata OGATAK at jp.ibm.com
Fri Sep 15 15:11:57 UTC 2017


Hi Peter,

My understanding is the case when dataLayout is speculatively loaded (and 
stored to the local variable slots) and then an element of ClassDataSlot 
array (say slots[0]) is also speculatively loaded.  I think the full fence 
should take effect when the speculative load of slots[0] is confirmed. 
Please correct me if I misunderstood.

Regards,
Ogata


Peter Levart <peter.levart at gmail.com> wrote on 2017/09/15 23:32:36:

> From: Peter Levart <peter.levart at gmail.com>
> To: Kazunori Ogata <OGATAK at jp.ibm.com>, Hans Boehm <hboehm at google.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
> Date: 2017/09/15 23:32
> Subject: Re: RFR: 8187033: [PPC] Imporve performance of 
> ObjectStreamClass.getClassDataLayout()
> 
> Hi,
> 
> On 09/15/2017 07:12 AM, Kazunori Ogata wrote:
> > Hi Hans,
> >
> > Thank you for your comment
> >
> > Hans Boehm <hboehm at google.com> wrote on 2017/09/15 09:44:56:
> >
> >> Just to be clear, the semi-plausible failure scenario here is that a
> >> reader will see a non-null slots value, but then read an 
uninitialized
> >> value from the ClassDataSlot array. This could happen if the compiler 
or
> >> hardware correctly speculated (e.g. based on a previous program
> >> execution), the value of dataLayout, used that to first load a value
> > from
> >> the ClassDataSlot array, and only then confirmed that the dataLayout
> > value
> >> was correct. None of this is likely to happen today, but is 
potentially
> >> profitable, and allowed by the current memory model. I think the 
extra
> >> assumption here should at least be documented.
> > In this scenario, the load from the ClassDataSlot array is also a
> > speculated load, so it should be confirmed after the load from 
dataLayout
> > is confirmed, and the full fence should be detected during the
> > confirmation of the speculated load from the array slot.  Otherwise, 
the
> > full fence won't work as expected, I think.
> 
> Just a reminder that the final code in question is the following:
> 
> 1196     ClassDataSlot[] getClassDataLayout() throws 
InvalidClassException {
> 1197         // REMIND: synchronize instead of relying on fullFence()?
> 1198         ClassDataSlot[] slots = dataLayout;
> 1199         if (slots == null) {
> 1200             slots = getClassDataLayout0();
> 1201             VarHandle.fullFence();
> 1202             dataLayout = slots;
> 1203         }
> 1204         return slots;
> 1205     }
> 
> Does speculative read of 'dataLayout' into local variable 'slots' mean 
> that 'slots' can change? Isn't this disallowed in Java (as apposed to 
C++)?
> 
> Regards, Peter
> 




More information about the core-libs-dev mailing list