RFR: 8187033: [PPC] Imporve performance of ObjectStreamClass.getClassDataLayout()
OGATAK at jp.ibm.com
Mon Sep 18 17:52:13 UTC 2017
Peter Levart <peter.levart at gmail.com> wrote on 2017/09/18 22:05:43:
> From: Peter Levart <peter.levart at gmail.com>
> To: Kazunori Ogata <OGATAK at jp.ibm.com>
> Cc: Hans Boehm <hboehm at google.com>, core-libs-dev
<core-libs-dev at openjdk.java.net>
> Date: 2017/09/18 22:06
> Subject: Re: RFR: 8187033: [PPC] Imporve performance of
> Hi Ogata,
> 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 should not raise any exception. If the confirmation at
> > succeeds, the value of tmp must also be correct because we put full
> > 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().
> > @Peter,
> > Thank you for the fix. I'll measure the performance.
> ClassDataLayout object (instead of ClassDataSlot array) is also an
> opportunity to put into it some pre-computed cached state which is
> re-computed frequently in ObjectInputStream.readSerialData and maybe
> also ObjectOutputStream.writeSerialData.
> I'll show the variant which pre-computes the 'hasSpecialReadMethod'
> value which is always recomputed in ObjectInputStream.readSerialData if
> your benchmark shows this is a promising direction...
Do you mean caching the result of ObjectStreamClass.hasReadObjectMethod()?
If so, can we cache it, though ObjectStreamClass.readObjectMethod is a
P.S. I'm waiting for finishing a long-running job on my machine. I'll
measure your patch tomorrow.
More information about the core-libs-dev