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

[Peter Levart]

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