-Xcheck: jni with JDK 1.8.0_60 now causes an avalanche of warnings

I've been using the java command line option -Xcheck: jni for years, without seeing much (all?) issues already raised, so far.

I just updated to the last JDK yesterday (1.8.0_60, for Windows 64-bit), and now my apps generate tons of console warning messages and stack traces.  At the end of this post, I list some of them.

Anyone know what is happening?

I did a web search, but found nothing related to what I see (just old posts like this).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Warning: local References NYI: zu, exceeds the capacity: zu

at java.lang.System.initProperties (Native Method)

at java.lang.System.initProperties (Native Method)

at java.lang.System.initProperties (Native Method)

at java.lang.System.initializeSystemClass (unknown Source)

at java.lang.System.initializeSystemClass (unknown Source)

at java.lang.System.initializeSystemClass (unknown Source)

Warning: local References NYI: zu, exceeds the capacity: zu

at java.net.NetworkInterface.getAll (Native Method)

at java.net.NetworkInterface.getNetworkInterfaces (unknown Source)

at sun.security.provider.SeedGenerator.addNetworkAdapterInfo (unknown Source)

to sun.security.provider.SeedGenerator.access$ 000 (unknown Source)

to sun.security.provider.SeedGenerator$ 1.run (unknown Source)

to sun.security.provider.SeedGenerator$ 1.run (unknown Source)

at java.security.AccessController.doPrivileged (Native Method)

at sun.security.provider.SeedGenerator.getSystemEntropy (unknown Source)

to sun.security.provider.SecureRandom$ SeederHolder. < clinit >(Unknown Source)

at sun.security.provider.SecureRandom.engineNextBytes (unknown Source)

-locked (a sun.security.provider.SecureRandom) < 0x00000000fc5ec1c0 >

at java.security.SecureRandom.nextBytes (unknown Source)

-locked < 0x00000000fc5ec4e0 > (a java.security.SecureRandom)

the impossible (unknown Source)

at java.util.Random.nextLong (unknown Source)

at org.mortbay.jetty.servlet.HashSessionIdManager.doStart(HashSessionIdManager.java:139)

...

WARNING in the native method: call NYI makes no exceptions check when required from CallStaticVoidMethod

at java.lang.ClassLoader.findBootstrapClass (Native Method)

at java.lang.ClassLoader.findBootstrapClassOrNull (unknown Source)

at java.lang.ClassLoader.loadClass (unknown Source)

-locked < 0x00000000fbd80198 > (a java.lang.Object)

at java.lang.ClassLoader.loadClass (unknown Source)

-locked < 0x00000000fbd800f0 > (a java.lang.Object)

to Sun.misc.Launcher$appclassloader$ AppClassLoader.loadClass (unknown Source)

at java.lang.ClassLoader.loadClass (unknown Source)

...

WARNING in the native method: call NYI makes no exceptions check when required from CallStaticVoidMethod

at java.io.FileOutputStream.writeBytes (Native Method)

the impossible (unknown Source)

at java.io.BufferedOutputStream.flushBuffer (unknown Source)

at java.io.BufferedOutputStream.flush (unknown Source)

-locked (a java.io.BufferedOutputStream) < 0x00000000f3c7b958 >

at java.io.PrintStream.write (unknown Source)

-locked < 0x00000000f3c7b938 > (a java.io.PrintStream)

at sun.nio.cs.StreamEncoder.writeBytes (unknown Source)

at sun.nio.cs.StreamEncoder.implFlushBuffer (unknown Source)

at sun.nio.cs.StreamEncoder.flushBuffer (unknown Source)

-locked < 0x00000000f3c7ba80 > (a java.io.OutputStreamWriter)

at java.io.OutputStreamWriter.flushBuffer (unknown Source)

at java.io.PrintStream.write (unknown Source)

-locked < 0x00000000f3c7b938 > (a java.io.PrintStream)

at java.io.PrintStream.print (unknown Source)

at java.io.PrintStream.println (unknown Source)

-locked < 0x00000000f3c7b938 > (a java.io.PrintStream)

...

WARNING in the native method: call NYI makes no exceptions check when required from CallStaticVoidMethod

at java.lang.Runtime.runFinalization0 (Native Method)

at java.lang.Runtime.runFinalization (unknown Source)

the impossible (unknown Source)

...

WARNING in the native method: call NYI makes no exceptions check when required from CallStaticVoidMethod

at java.net.SocketOutputStream.socketWrite0 (Native Method)

at java.net.SocketOutputStream.socketWrite (unknown Source)

at java.net.SocketOutputStream.write (unknown Source)

at java.io.BufferedOutputStream.flushBuffer (unknown Source)

at java.io.BufferedOutputStream.flush (unknown Source)

-locked (a java.io.BufferedOutputStream) < 0x00000000f45962f0 >

at java.io.DataOutputStream.flush (unknown Source)

...

This would be a result of JDK-8043224 "-Xcheck:jni improvements to exception checking and excessive local refs. There were a few checks additional paranoia made, many of the warnings are theoretically correct, but in practice, no dangerous product.

Local refs JNI example: application in the Hotspot JVM, these blocks of memory for JNI references automatically push. For programs that are actually fleeing too much memory by mistake, this warning is not so useful. Other implementations of JVM (namely those who have memory constraints) may very well require according to the JNI specification more space to handle is explicitly requested (for example EnsureLocalCapacity).

If the warnings produced by - Xcheck: jni have been added to the JNI specification in mind, allowing users to find potential problems, even when the JVM implementations.

Some of the warning of the native code of the JDK are produced by the code of boot/bootstrap, which some has not changed for a long time, and are of nature if X did not work the JVM cannot work at all. It would be nice to remove some of these warnings, if... probably over time, since - Xcheck: jni is not something we would use in production.

Tags: Java

Similar Questions

Maybe you are looking for