JDK-8160614 : Some of the checked JNI improvements are excessively verbose
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 8u60,9
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2016-06-30
  • Updated: 2016-12-19
  • Resolved: 2016-09-16
Related Reports
Relates :  
Relates :  
Relates :  
Propose the introduction of "-Xcheck:jniverbose" and move some of the more expensive and verbose "-Xcheck:jni" features into the "jniverbose".

8043224: -Xcheck:jni improvements to exception checking and excessive local refs

Adds warnings for every time the user has not checked for pending exceptions, the warnings are emitted for every call site, even when is no pending exception. This as caused some grief with code that may make a single check for batches of calls, excessive warnings are produced, this leads to testing timeouts in some cases.

6311046: -Xcheck:jni should support checking of GetPrimitiveArrayCritical

The guarded memory checks here are very expensive for high throughput, like AWT event testing, it's been causing timeouts.

Folks in the wild are also affected, e.g.: https://community.oracle.com/thread/3783234

Behavior changes:

* check_exceptions should only warn if there is a pending exception (same as previous to 8043224)
* guarded memory not used (same as previous to 6311046) 

* check_exceptions complains pedantically for every unchecked call, as-per 8043224
* guarded memory used as per 6311046

Reduced verbosity with the fix in JDK-8164086..."Xcheck:jni" is pedantic, dubious if multiple levels will help anything.

JDK-8164086 means single JNI calls shall no longer produce warnings, which was the source of a fair amount of needless verbosity. Furthermore, static code checking of the JDK already reports missing exception check warnings.

[~dholmes] Agreed, will address the return to Java issue in a separate bug, and see if we can just close this one.

I think the issue encountered by the JDK code is that the JNI-checks are incomplete. If the thread transitions back to Java then clear_pending_jni_exception_check() needs to be called. So only if you stay in C code will two consecutive JNI calls, with no pending exception check, trigger the warning.

Not sure I agree here. Batching calls that can themselves throw exceptions requires exception checks before the next call. Test affected by this should be fixed.

Introduced by 6311046 and 8043224