JDK-8046668 : Excessive checked JNI warnings from Java startup
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-06-12
  • Updated: 2015-09-29
  • Resolved: 2014-07-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u60Fixed 9 b25Fixed
Related Reports
Duplicate :  
JDK-8048626 - JNI call made without checking exceptions when required to from GetStringUTFRegion
Relates :  
JDK-8043224 - -Xcheck:jni improvements to exception checking and excessive local refs
Description
Since adding preemptive warnings to JNI functions that have not previously checked for expections (JDK-8043224) running "-Xcheck:jni -version" produces numerous such warnings. E.g.:

...
WARNING in native method: JNI call made without checking exceptions when required to from GetByteArrayRegion
	at java.lang.Object.getClass(Native Method)
	at java.lang.ClassLoader.<init>(ClassLoader.java:284)
	at java.lang.ClassLoader.<init>(ClassLoader.java:318)
	at java.security.SecureClassLoader.<init>(SecureClassLoader.java:76)
	at java.net.URLClassLoader.<init>(URLClassLoader.java:188)
	at sun.misc.Launcher$AppClassLoader.<init>(Launcher.java:292)
	at sun.misc.Launcher$AppClassLoader$1.run(Launcher.java:283)
	at sun.misc.Launcher$AppClassLoader$1.run(Launcher.java:279)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.misc.Launcher$AppClassLoader.getAppClassLoader(Launcher.java:278)
	at sun.misc.Launcher.<init>(Launcher.java:79)
	at sun.misc.Launcher.<clinit>(Launcher.java:57)
	at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1443)
	- locked <0x00000000d7000b08> (a java.lang.Class for java.lang.ClassLoader)
	at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1428)
WARNING in native method: JNI call made without checking exceptions when required to from GetStringUTFRegion
	at java.lang.Object.getClass(Native Method)
	at java.lang.invoke.MethodHandleImpl.initStatics(MethodHandleImpl.java:51)
	at java.lang.invoke.MethodHandle.<clinit>(MethodHandle.java:426)

Similarly, excessive local reference growth. E.g:
...
WARNING: JNI local refs: 37, exceeds capacity: 34
        at java.lang.System.initProperties(Native Method)
        at java.lang.System.initializeSystemClass(System.java:1160)
...

Two main causes:
A) Early start up where checks make little to no sense.
  - Disable these warnings.
B) Actual sloppy JNI code.
  - Identify and fix
Comments
After going through start up (-version) and "fixing missing" exception checks, it appears most involved JNI functions are those that potentially throw ArrayIndexOutOfBoundsException. But all of the affected code always checked length, and Java arrays and strings have immutable length, so having to place ExceptionCheck is way to pedantic. For example: jint len = (*env)->GetArrayLength(env, arr); ... (*env)->GetByteArrayRegion(env, hab, 0, len, (jbyte *)result); // Potential ArrayIndexOutOfBoundsException...BUT I CHECKED THE LENGTH, THIS ISN'T MEANINGFUL if ((*env)->ExceptionCheck(env)) { assert(0 && "should not reach here"); .... Following checked JNI functions whilst technically may throw ArrayIndexOutOfBoundsException, should relax and not insist on exception check: GetObjectArrayElement SetObjectArrayElement Get<type>ArrayRegion Set<type>ArrayRegion GetStringRegion GetStringUTFRegion
13-06-2014
There is a bug in the excessive local refs warning code, where by the JNI handle "planned capacity" does not account for the current number of live handles.
13-06-2014