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

Kazunori Ogata OGATAK at jp.ibm.com
Mon Sep 18 17:52:13 UTC 2017

Hi Peter,

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 
> ObjectStreamClass.getClassDataLayout()
> 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[17] 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 
mutable field?


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 mailing list