RFR (S): JDK-8164086: Checked JNI pending exception check should be cleared when returning to Java frame
David Holmes
david.holmes at oracle.com
Fri Aug 19 12:29:12 UTC 2016
Hi David,
On 19/08/2016 9:20 PM, David Simms wrote:
> Greetings,
>
> JDK-8043224 Added warnings when using -Xcheck:jni when native code using
> the JNI API fails to check for exceptions. Returning to a Java frame
> should implicitly clear the need for checking for exceptions. Current
> JVM code does not, leading to a fair amount of false warnings from JDK
> core libraries.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8164086
>
> Webrev: http://cr.openjdk.java.net/~dsimms/8164086/webrev0/
The changes in the native wrapper seem okay though I'm not an expert on
the machine specific encodings.
I'm a little surprised there are not more things that need changing
though. Does the JIT use those wrappers too? Can we transition from Java
to VM to native and then back - and if so might we need to clear the
pending exception check? (I'm not sure if from in the VM a native call
could actually be a JNI call, or will only be a direct native call?).
Did you intend to leave in the changes to
jdk/src/java.base/share/native/libjli/java.c? It looks like debug/test
code to me.
The test I'm finding a bit hard to follow but don't you need to check
for pending exceptions here:
29 static jmethodID get_method_id(JNIEnv *env, jclass clz, jstring
jname, jstring jsig) {
30 jmethodID mid;
31 const char *name, *sig;
32 name = (*env)->GetStringUTFChars(env, jname, NULL);
33 sig = (*env)->GetStringUTFChars(env, jsig, NULL);
34 mid = (*env)->GetMethodID(env, clz, name, sig);
to avoid triggering the warning?
Thanks,
David H.
(PS. calling it a night)
> Testing: added a new jtreg test including some JNI use cases which
> should and should not produce warnings, passes on all platforms.
>
> /David Simms
>
More information about the hotspot-runtime-dev
mailing list