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

Hans Boehm hboehm at google.com
Mon Sep 18 20:47:12 UTC 2017


On Mon, Sep 18, 2017 at 10:52 AM, Kazunori Ogata <OGATAK at jp.ibm.com> wrote:
>
> Hi Peter,
>
> Peter Levart <peter.levart at gmail.com> wrote on 2017/09/18 22:05:43:
>
> > On 09/18/2017 12:28 PM, Kazunori Ogata wrote:
> > > Hi Hans and Peter,
> > >
> > > Thank you for your comments.
> > >
> > > Regarding the code Hans showed, I don't yet understand what it the
> > > problem.  Since the load at 1204b is a speculative one, dereferencing
> > > slots[17] should not raise any exception.  If the confirmation at
> 1204.5
> > > succeeds, the value of tmp must also be correct because we put full
> fence
> > > and we see a non-NULL reference that was stored after the full fence.
> >
> > I don't know much, but I can imagine that speculative read may see the
> > value and guess it correctly based on let's say some CPU state of
> > half-processed write instruction in the pipeline, which is established
> > even before the fence instruction flushes writes to array slots. So I
> > can accept that such outcome is possible and doesn't violate JMM.
>
> This seems to me that the processor/platform can't implement full fence
> correctly.  I think it is the platform's (processor's and compiler's)
> responsibility to support full fence, otherwise the platform can't
> implement all Java API, including VarHandle.fullFence().

As Peter said, my concern is not with exceptions, but with seeing
uninitialized
data for slots[17].

The semantics of "full fences" are tricky, but basically they don't restrict
reordering in other threads, only the thread that executed the fence. The
thread
with the problematic reordering here is the one that saw a non-null
dataLayout value, and hence did not execute a fence.

Hence fences generally have to be paired with either another fence in the
other
thread, or some other ordering mechanism. That other ordering mechanism is
missing here, though many implementations will ensure correct ordering, due
to
hardware dependence-based ordering guarantees. But the JMM does not
promise that.

Hans


More information about the core-libs-dev mailing list