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

[Kazunori Ogata]

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 
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().

<snip>

> > @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?


Regards,
Ogata


P.S. I'm waiting for finishing a long-running job on my machine.  I'll 
measure your patch tomorrow.