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 
> the ClassDataSlot array, and only then confirmed that the dataLayout 
> 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.


More information about the core-libs-dev mailing list