Memory fences in the JNI invocation on Power

[Doerr, Martin]

Hi Michihiro,

the change is incorrect.
You need a StoreLoad barrier between the thread state change and the succeeding safepoint check.
The transition state must be visible when reaching the safepoint.

Note that I've recently contributed FastJNIAccessors for PPC64:
https://bugs.openjdk.java.net/browse/JDK-8228743
But this only speeds up reading primitive fields in native code.

If there are methods which execute quickly and only need to pass primitive types and arrays of primitive types, you may want to take a look at CriticalJNINatives.
There are jtreg tests which implement JavaCritical_ native methods, e.g.:
test/hotspot/jtreg/gc/libCriticalNative.c
It's also used by src/jdk.crypto.ucrypto/solaris/native/libj2ucrypto/nativeCryptoMD.c

Best regards,
Martin


From: ppc-aix-port-dev <ppc-aix-port-dev-bounces at openjdk.java.net> On Behalf Of Michihiro Horie
Sent: Montag, 9. September 2019 16:15
To: ppc-aix-port-dev at openjdk.java.net
Subject: Memory fences in the JNI invocation on Power


Hi all,

This is not a RFR. I have a client case in which a Java application invokes JNI methods heavily on Power.

Fixing Java code is not allowed, so I'm wondering if there is any way to enlighten the JNI invocation by replacing memory fences such as the following diff on Power. I may miss the design around the diff, but I'm not sure if WR order needs to be protected.
http://cr.openjdk.java.net/~mhorie/webrev_jni/
(I should fix code under the given abstractions, but wanted to share a fix on Power in the first place.)

Best regards,
Michihiro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20190909/4dd671e2/attachment.html>