Hi,
On 09/15/2017 07:12 AM, Kazunori Ogata wrote:
Hi Hans,
Thank you for your comment
Hans Boehm <[email protected]> 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
