RFR: 8187033: [PPC] Imporve performance of ObjectStreamClass.getClassDataLayout()
Peter Levart
peter.levart at gmail.com
Mon Sep 4 09:07:37 UTC 2017
Hi,
Maybe a more knowledgeable soul could shed some light into an internal
@Stable annotation...
It was meant to be used internally in the java.lang.invoke package, but
in JDK 9 it was made public, not exported, so it can be used in the
entire java.base module. There are already some usages in java.util
package and recently, sun.nio.cs.StandardCharsets added a usage in JDK
10. When @Stable annotation was designed it was debated whether @Stable
instance fields should get the treatment of final instance fields as far
as JMM is concerned. So the question is, was this suggestion actually
implemented in the VM. Scanning the usages in JDK 10, I can see that all
@Stable instance fields of array type(s) are also marked with final
modifier. Except one:
java.lang.invoke.VarForm#methodType_V_table
Is this an oversight or a consequence of @Stable implying the memory
order semantics of final?
If it is the later, then perhaps Ogata could simply put @Stable in front
of dataLayout field.
Regards, Peter
On 09/04/2017 07:20 AM, Kazunori Ogata wrote:
> Hi Aleksey and Hans,
>
> I implemented four variations of changes and measured performance
> improvement.
>
> 1) Put VarHandle.fullFence() between initialization of ClassDataSlot[] and
> writing the reference to non-volatile dataLayout.
> Webrev: http://cr.openjdk.java.net/~horii/8187033/webrev.01-fence/
>
> 2) Use Unsafe.getObjectAcquire() and Unsafe.putObjectRelease() for
> reading/writing dataLayout.
> Webrev: http://cr.openjdk.java.net/~horii/8187033/webrev.01-unsafe/
>
> 3) Put reference to ClassDataSlot[] into a final field of an object and
> store the object to non-volatile dataLayout. Every invocation of
> getDataLayout() reads the final field needs to deference the object
> pointer.
> Webrev: http://cr.openjdk.java.net/~horii/8187033/webrev.01-final/
>
> 4) Put reference to ClassDataSlot[] into a final field of an object, read
> the final field immediately after the object creation, and store it to
> non-volatile dataLayout. I think this is also correct based on the
> semantics of final fields and data dependency.
> Webrev: http://cr.openjdk.java.net/~horii/8187033/webrev.01-final2/
>
>
> The performance improvements were:
>
> 1) +3.5%
> 2) +1.1%
> 3) +2.2%
> 4) +3.4%
>
> The reason of small improvement in 2) is that the actual code of
> Unsafe.getObjectAcquire()/putObjectRelease() simply invokes
> getObjectVolatile()/putObjectVolatile() in them, respectively.
>
>
> If all implementations are correct, I'd like to take 4) because I want to
> back port this change to jdk8u but VarHandle is only available in jdk9 or
> later.
>
>
> Regards,
> Ogata
>
More information about the core-libs-dev
mailing list