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
