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