Memory fences in the JNI invocation on Power

[Michihiro Horie]

Hi Martin,

Thanks a lot for your quick response. I see, we cannot apply this fix.
I will look for an opportunity in which FastJNIAccessor is applicable.

Best regards,
Michihiro



From:	"Doerr, Martin" <martin.doerr at sap.com>
To:	Michihiro Horie <HORIE at jp.ibm.com>,
            "ppc-aix-port-dev at openjdk.java.net"
            <ppc-aix-port-dev at openjdk.java.net>
Date:	2019/09/10 00:34
Subject:	[EXTERNAL] RE: Memory fences in the JNI invocation on Power



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/20190910/b80dacde/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20190910/b80dacde/graycol-0001.gif>