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

[Peter Levart]

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
>