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?

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