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

[Hans Boehm]

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.

Answering Andrew's earlier question (sorry), this could conceivably become
an issue if the hardware provided multiple load instructions, one for
final-field, and one for non-final-field loads, only the former of which
implicitly enforced dependency ordering. The latter could behave like DEC
Alpha's load. I'll let any hardware architects comment as to whether or not
that might make sense.

On Thu, Sep 14, 2017 at 8:09 AM, Kazunori Ogata <OGATAK at jp.ibm.com> wrote:

> Hi Roger,
>
> Thank you for taking care of this patch and offering to sponsor it.
>
> Regards,
> Ogata
>
>
> "core-libs-dev" <core-libs-dev-bounces at openjdk.java.net> wrote on
> 2017/09/14 22:34:38:
>
> > From: Roger Riggs <Roger.Riggs at Oracle.com>
> > To: core-libs-dev at openjdk.java.net
> > Date: 2017/09/14 22:36
> > Subject: Re: RFR: 8187033: [PPC] Imporve performance of
> > ObjectStreamClass.getClassDataLayout()
> > Sent by: "core-libs-dev" <core-libs-dev-bounces at openjdk.java.net>
> >
> > Hi,
> >
> > The repo's are closed in the short term for the consolidation.
> >
> > It seems like the consensus is that full fence is the best solution.
> >
> > I can sponsor the issue when the jdk 10 repos re-opens.
> >
> > Regards, Roger
>
>
>