RFR: 8187033: [PPC] Imporve performance of ObjectStreamClass.getClassDataLayout()
Kazunori Ogata
OGATAK at jp.ibm.com
Fri Sep 15 05:12:00 UTC 2017
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.
Regards,
Ogata
More information about the core-libs-dev
mailing list