Note:
For information about bug fixes in the JDK, see the JDK 6 Release Notes.
It contains the following sections:
For information about bug fixes in the JDK, see the JDK 6 Release Notes.
The following issues have been fixed in Oracle JRockit JDK R28.3.19. For more information about bug fixes and other changes in the JDK, see the JDK 6 Release Notes.
If an x86 or x86_64 Processor reports (via CPUID) more than 128 logical processors per package, earlier versions of JRockit would hang during startup.
When using Linux on some newer x86 or x86_64 processors, the additional stack space required to save the state of newly added registers may cause earlier versions of JRockit to run out of stack space and crash during signal handling. In environments where this issue happens, JRockit will crash immediately during startup and will not output a text crash file (jrockit.<pid>.dump). Currently the only processors known to trigger this issue all support various versions of the AVX-512 instruction set extension.
The following issues have been fixed in Oracle JRockit JDK R28.3.18. For more information about bug fixes and other changes in the JDK, see the JDK 6 Release Notes.
A regression was introduced in JRockit R28.3.17 that may prevent JRockit from correctly loading a java.util.ResourceBundle via the reflection API. One common symptom of this issue is a java.util.MissingResourceException being thrown while running the WebLogic Scripting Tool (WLST).
For information about bug fixes in the JDK, see the JDK 6 Release Notes.
For information about bug fixes in the JDK, see the JDK 6 Release Notes.
For information about bug fixes in the JDK, see the JDK 6 Release Notes.
The following issues have been fixed in Oracle JRockit JDK R28.3.14. For more information about bug fixes and other changes in the JDK, see the JDK 6 Release Notes.
security-libs/javax.net.ssl
A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an IllegalArgumentException thrown by the TLS handshaker code.
java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves
The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified.
See JDK-8173783
For information about bug fixes in the JDK, see the JDK 6 Release Notes.
The following issues have been fixed in Oracle JRockit JDK R28.3.12. For more information about bug fixes and other changes in the JDK, see the JDK 6 Release Notes.
The class library is normally kept in sync between HotSpot-based and JRockit-based JDKs, but the fix for JDK bug 8068427 was not included in the previous JRockit release, R28.3.11 (JDK 6u121). This fix is included in this release.
The following issues have been fixed in Oracle JRockit JDK R28.3.11:
A regression was introduced in JRockit R28.3.10 that may cause corruption of data stored on the Java heap resulting in crashes and other unexpected behavior.
This issue has been fixed.
Under certain circumstances, the amount of dark matter (fragmentation) reported by heap diagnostics (heap_diagnostics and HeapDiagnosticsOnOutOfMemoryError) would be incorrect. Often this would manifest as an impossibly large value (larger than the total heap size) being reported.
This issue has been resolved.
Heap diagnostics (as output by the HeapDiagnosticsOnOutOfMemoryError command line flag or the heap_diagnostics diagnostic command) could contain errors when instances of a single class collectively consume 2 GB or more of heap space. Specifically, such classes may be displayed with an incorrect delta value (the calculated difference with the previous heap diagnostic output) and may appear in an incorrect position (out of sort order) within the list of classes. Trend analysis sort order in the Memory Leak Detector may also be impacted.
This issue has been resolved.
On SPARC T2-based systems, JRockit did not utilise direct floating point hardware support for square root calculations (that is, Math.sqrt()). Instead, such calculations were done in software using simpler instructions.
This issue has been resolved, and now JRockit will utilise the fsqrtd instruction for such calculations. As a result, applications which call Math.sqrt() frequently may experience a performance improvement.
On SPARC-based systems, sometimes the number of CPU cores could not be correctly identified.
This issue has now been resolved. On SPARC T1, T2, and T3 systems only, the number of CPU cores detected is used to calculate the default number of GC worker threads. (There is no other impact from this change, regardless of CPU).
In the rare event that this change negatively impacts the performance of a given application, the number GC worker threads can be specified with the -XXgcThreads command-line option. The number of each type of GC worker thread used by previous versions of JRockit in a given environment can be confirmed by examining -Xverbose GC debug output. For example:
$ <OLD_JROCKIT_HOME>/bin/java -Xverbose:gc=debug -version . < . . . > [DEBUG][memory ] Initial and maximum number of gc threads: 8, of which 8 parallel threads, 4 concurrent threads, and 8 yc threads. < . . . > . $ <NEW_JROCKIT_HOME>/bin/java -XXgcThreads:yc=8,con=4,par=8 MyJavaApplication
On SPARC systems equipped with a CPU that supports Realtime Silicon Secured Memory, a stale memory reference would be detected during JVM startup. This would result in a crash when using libadimalloc, the Application Data Integrity aware memory allocation library, preventing its use with JRockit.
This issue has been resolved.
The JRockit compiler, when optimizing code that calls the java.lang.System.arraycopy() method, may generate incorrect code resulting in erroneous computation results. This issue often manifests as an unexpected ArrayIndexOutOfBoundsException.
This issue has been resolved.
The following issues have been fixed in Oracle JRockit JDK R28.3.10:
When a Java heap exhaustion (a type of OutOfMemoryError condition) happens, JRockit would sometimes crash while executing the constpoolwrapper_finalize function. This issue has been resolved.
However, for any type of OutOfMemoryError condition, Oracle recommends that you identify and resolve the root cause of the memory exhaustion regardless of this change.
A race on VM startup between class loading and JIT compilation may result in incorrectly generated code. The behavior of such code is undefined, but has been known to manifest as a JVM crash, often accompanied by a SIGTRAP signal or a 'No exception handler found [56]' error message.
This issue has been resolved.
The JRockit compiler, when inlining a method which has no normal return paths (that is, it only throws exceptions), may generate incorrect code resulting in erroneous computation results. The JVM may hang, crash, or exhibit other undefined behavior.
This issue has been resolved.
The following issues have been fixed in Oracle JRockit JDK R28.3.9:
In certain circumstances, ObjectStreamClass.lookup() could return a non-null result even when a non-serializable class is passed. This could result in various serialization issues and other incorrect behavior.
This issue has been resolved.
Under certain circumstances, the JRockit process may hang soon after a NULL pointer is passed (in place of a char array) as the second argument to the JNI NewStringUTF function. As native code within the Java runtime itself may trigger this issue, even systems that do not use third party JNI libraries may be susceptible.
This issue has been resolved.
The following issues have been fixed in Oracle JRockit JDK R28.3.8:
On Linux kernels 2.6 and later, JRockit would include time spent waiting for IO completion as "CPU usage". During periods of heavy IO activity, this could result in misleadingly high values reported as CPU consumption in various tools like Flight Recorder, performance counters, and the cpuload diagnostic command.
This issue has been resolved.
The following issues have been fixed in Oracle JRockit JDK R28.3.6:
Bug 12943958
Running Java applications compiled with javac in debug mode (using the "-g" option) might result in a JVM crash. This happens when you have specified -Xdebug or -XX:+JavaDebug option at JVM startup. The incorrect debugging information in some class files generated by Oracle javac caused this issue.
This issue has been fixed in Oracle JRockit JDK R28.3.6. After upgrading, recompile the classes using the fixed version of javac.
The following issues have been fixed in Oracle JRockit JDK R28.3.5:
Previous versions of JRockit R28 were unable to correctly instrument Java methods that used generics. This resulted in the inability to profile such methods with the JMXMAPI profiling API or JRockit Mission Control Console's profiler.
This issue has been resolved.
The following issues have been fixed in Oracle JRockit JDK R28.3.4:
The default options that are passed to the JRockit JVM during invocation of various command-line tools such as jps, jrcmd, and jstat have been changed to reduce the amount of native memory required.
When copying huge arrays, the array size (or offsets) measured in elements could be converted to an array size in bytes for some copies and this could overflow the size of a 32-bit integer, leading to a copy that does not terminate correctly and rarely causing a JVM crash.
This issue has been resolved.
The following issues have been fixed in Oracle JRockit JDK R28.3.2:
In previous versions of JRockit R28, if the default recording and/or buffering to disk is enabled by using the -XX:FlightRecorderOptions command-line option and when you start a new recording using the -XX:StartFlightRecording option, JRockit would sometimes hang indefinitely during startup. For more information about the command-line options and parameters, see JRockit Command-Line Reference.
This issue has been resolved.
In previous versions of JRockit, the value of -XX:+|-CheckStacks option was ignored on SPARC platform.
This issue has been resolved. In JRockit R28.3.2, the -XX:+|-CheckStacks option is implemented correctly.
In certain cases, when a method invoked implicit or explicit boxing operations, a NullPointerException was thrown from the method. An issue existed in the code optimization that caused this exception.
This issue has been resolved.
The following issues have been fixed in Oracle JRockit JDK R28.2.9:
The JVM could deadlock when creating an hprof dump on OutOfMemoryError if you are using the JVM flag -XX:+HeapDumpOnOutOfMemoryError.
This issue has been resolved.
The following issues have been fixed in Oracle JRockit JDK R28.2.8:
In JRockit releases R28.2.6 and R28.2.7, a known issue exists wherein, under rare circumstances, a call to Package.getPackages may result in a NullPointerException in Package.defineSystemPackage. This issue has been resolved.
A race on VM startup between class loading and serialization of classes could result in sporadic NullPointerExceptions from Class.isAssignable in java.lang package. This issue has been resolved.
The following issues have been fixed in Oracle JRockit JDK R28.2.6:
When using certain settings in a custom .jfs file, the Oracle JRockit Flight Recorder repository could, under some circumstances, continue growing indefinitely, even when limited by maxsize settings. This has been fixed.
Applications that dynamically created classes (for example, by using JAXB) could run out of native memory, crash, or exhibit other unexpected behaviors due to an internal reference counting issue that could eventually corrupt memory or allow unused classname strings to accumulate after their referring classes were unloaded. This has been fixed.
Previous versions of the JMXMAPI profiling API could only profile a single instance of a class with the same name. If multiple class loaders loaded the same class, only one version of the class would be instrumented. Now all versions of a class (with the same fully qualified class name) will be instrumented. This change also impacts JRockit Mission Control Console's profiling functionality (there is no impact to JFR profiling).
The following issues have been fixed in Oracle JRockit JDK R28.2.5:
Bug 14271750
Under rare circumstances, JRockit would crash manipulating shared resources from multiple threads, mostly involving interning Java Strings concurrently from multiple threads. This issue has been fixed.
Bug 14268514
In rare conditions, the JRockit JVM would crash if compiler directives are used in an optfile. This issue has been fixed.
Bug 14093205
In previous JRockit versions, from R28.0.0 to R28.2.4, if the standard input stream was a pipe and if it was closed by the application, subsequent attempts to read other FileInputStreams could incorrectly result in a FileNotFoundException error. This issue has been fixed.
Bug 14047648
Under certain circumstances, JRockit would hang while closing a NIO Socket. This issue has been fixed.
Bug 13925641
When a SecurityManager is used on Windows, certain NIO operations used to fail with an AccessControlException. This issue has been fixed.
Bug 13350796
In previous versions of JRockit, when an application tried to use the Flight Recorder API while running on a JRockit instance where Flight Recorder is disabled, a java.lang.Error would be thrown. This behavior has been changed so that java.lang.IllegalStateException is thrown instead. New explanatory text has also been added to the exception.
Bug 14266485
JRockit crashes with illegal memory access in long [] com.sun.management.getThreadCpuTime(long[] ids) method due to incomplete implementation of com.sun.management extensions.
The array version of ThreadMXBean.getThreadCpuTime() has been implemented in Oracle JRockit R28.2.5. The issue has been resolved.
The following issues have been fixed in Oracle JRockit JDK R28.2.4:
A regression was introduced in JRockit R28.2.3 where the "stop" statement was ignored by the jrcmd command. This issue has been fixed.
In previous versions, JRockit could select the wrong compressed reference size and fail to start on Solaris while using a page size over 1 GB. This issue has been fixed.
The following issues have been fixed in Oracle JRockit JDK R28.2.3:
In earlier versions of JRockit, the jrcmd command was not redirecting the output to the file specified by the set_filename diagnostic command. In JRockit R28.2.3, if an output file is specified by the set_filename command, output from diagnostic commands invoked by jrcmd will be redirected to the file in the same manner as the output is redirected by the diagnostic commands that you run by the control break handler (SIGQUIT).
By default, the output from diagnostic commands invoked by jrcmd is sent to the STDOUT output stream of the jrcmd process. To reset the default behaviour of the set_filename command, run the command without specifying a value for the filename argument. For more information, see "Diagnostic Commands" in the JRockit Command-Line Reference.
In earlier releases of JRockit, the jrcmd command limited the size of a file passed using the -f option to a maximum of 256 bytes. From JRockit 28.2.3 onwards, the file size is unlimited, but each line in the file is limited to 256 bytes.
There was a regression introduced in JRockit R28.2.0 that could cause JRockit to crash during the vmsiReserve method on specific platforms. This issue has been fixed.
JRockit used to crash during a stack overflow under some conditions, not having enough space to run its own signal handler, causing the process to abort rather than throwing a StackOverflowError. This issue has been fixed.
Under rare circumstances, JRockit would crash when optimizing a method, often a method in the java/util/regex package. This issue has been fixed.
The following issues have been fixed in Oracle JRockit JDK R28.2.2:
A regression in Java SE 6 Update 29 caused SSL connection failure while using the TLS_DH_anon_WITH_AES_128_CBC_SHA cipher suite. This issue has been fixed.
A bug in string append optimization could lead to a crash in JRockit JVM, often during garbage collection. This issue has been fixed.
The following issues have been fixed in Oracle JRockit JDK R28.1.5:
Bug 12599685
On a 64-bit platform, JRockit could run out of space in the low 4-GB address space of the Java heap and cause OutofMemory error during class allocation.
To avoid this error, you can reserve memory in the low 4-GB heap during the JVM startup by using the -XX:InitialClassBlockMemory option as follows:
-XX:+UnlockDiagnosticVMOptions -XX:InitialClassBlockMemory=100M
Bug 12620601
The default value of garbage collection threads specified by the -XXgcThreads option was based on the number of cores and hardware threads on the machine.
The heuristics for garbage collection has been improved to select dynamic number of garbage collection threads. The number of garbage collection threads dynamically selected is now more conservative on large multi-core machines in order to reduce overhead.
The following issues have been fixed in Oracle JRockit JDK R28.1.4:
Bug 12355103
When launching Java involving symbolic links on Windows, Oracle JRockit would sometimes print a warning, such as:
[WARN ][osal ] Could not add counter \Virtual Bytes for query [WARN ][osal ] Failed to init virtual size counter.
This has been fixed.
The following issues have been fixed in Oracle JRockit JDK R28.1.3:
Bug 11769358
Occasionally, if a custom file protocol handler was in place, a deadlock would occur in the ClassLoader. This has been fixed; this fix resolves Sun Bug 7001933.
Bug 11769385
The exception javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated was unexpectedly being thrown. This has been fixed; this fix resolves Sun Bug 6924489.
Bug 11769415
Setting SO_RCVBUF/SO_SNDBUF to a value larger than tcp_max_buf failed on Solaris 11 if the kernel parameters changed. This has been fixed; this fix resolves Sun Bug 6984182.
Bug 11709391
Passing a read-only bytebuffer to a channel write method could throw a java.nio.ReadOnlyByteBufferException. This has been fixed.
Bug 10415204
JNI API Get<PrimitiveType>ArrayElements routines did not correctly set isCopy parameter to JNI_TRUE when returning copies. This has been fixed.
The following issues have been fixed in Oracle JRockit JDK R28.1.1:
Bug 10164002
Previously, while it was conducting a concurrent sweep without a nursery, Oracle JRockit might crash if it tried to allocate an object from JNI that was the exact size of the minimum thread local area size. This has been fixed.
Bug 10295969
R28.0.0 and later silently exit if a command-line option was misspelled; for example, "-X:MaximumNurseryPercentage=80" (note the single X where XX is required). This has been fixed in R28.1.1.
Bug 10296987
In rare cases, Oracle JRockit could erroneously optimize an arraycopy to reuse the source array as the target array. This could lead to the wrong values being read from the source array after the arraycopy. This has been fixed.
Bug 10301830
When calling SecureRandom.generateSeed, the JDK would always read 8192 bytes from the entropy pool. The JDK has been changed to only read the number of bytes requested. For more information, see:
The following issues have been fixed in Oracle JRockit JDK R28.1.0:
Oracle JRockit would hang during startup when Oracle WebLogic Server was started with an application management solution such as CA Wily Introscope.
This issue has been fixed in JRockit R28.1.0.
A memory leakage used to occur in the JMX implementation of JDK 6. This issue has been fixed by Sun in JDK 6 Update 22.
The fix is included in JRockit R28.1.0.
If the -XX:+|-ExitOnOutOfMemoryError option was enabled, JRockit would exit when aborting an optimization due to the compiler memory limit.
This issue has been fixed in JRockit R28.1.0.
When the heap size was 2 GB or higher, JRockit would write segmented heap dumps that Eclipse Memory Analyzer (MAT) could not parse.
This issue has been fixed in JRockit R28.1.0.
When you invoke methods using the class reflection feature, JRockit would sometimes throw an exception type that is different from the signature of the Method.invoke() method.
This issue has been fixed in JRockit R28.1.0. Invoking methods using reflection now throws the correct InvocationTargetException type.
The following issues have been fixed in Oracle JRockit JDK R28.0.2:
Bug 9714564
On some Solaris machines, Oracle JRockit would start slowly, printing warnings; for example:
[WARN ][osal ] Failed to initialize kstat for CPU 0, ignoring
This issue has been fixed in release R28.0.2.
Bug 9728938
IO exceptions originating from the epoll socket muxer would occasionally throw NoClassDefFoundErrors when trying to find the java/lang/IOException class. This issue has been fixed in release R28.0.2.
Bug 9763391
Occasionally, while pruning references to obsoleted code, Oracle JRockit would crash in Code_and_classgc_background_task. This issue has been fixed in release R28.0.2.
Bug 9795028
In previous Oracle JRockit releases, the JVM could not open JAR or ZIP files larger than 2GB. This issue has been fixed in release R28.0.2.
The following issues have been fixed in Oracle JRockit JDK R28.0.1.
Bug 9475801
The JVM crashes when it encounters non-UTF8 characters in a compiler control directives file.
This issue has been fixed in R28.0.1.
Bug 9343546
In certain cases involving try-catch clauses, the JVM incorrectly optimizes or proves a null-check as always failing.
This issue has been fixed in R28.0.1.
Bug 9466275
On Linux systems, the JVM crashes at startup if the user sets libjsig.so (the signal chaining library) to be preloaded through the LD_PRELOAD=libjsig.so environment variable. This prevents some third-party JNI libraries from being used with Oracle JRockit R28. To download a patch for this issue, see patch ID 9586671 for JDK 6 and patch ID 9672120 for JDK 5.
This issue has been fixed in R28.0.1.
Bug 9485661
In certain cases, the NIO selector functionality fails unless net.dll is loaded before nio.dll. This happens only when using JAVA_HOME\bin\java as opposed to JAVA_HOME\jre\bin\java. To download a patch for this issue, see patch ID 9586671 for JDK 6 and patch ID 9672120 for JDK 5.
This issue has been fixed in R28.0.1.
Bug 9631915
When the deprecated command-line option -XXexternalCompactRatio is used, the following incorrect warning is displayed.
[WARN ] -XXexternalCompactRatio is a deprecated option. Please use -XXcompaction:internalPercentage instead.
This issue has been fixed in R28.0.1.
Bug 9671985
When the java.util.zip.ZipEntry created for an uncompressed entry (method STORED) is initialized, the uncompressed and compressed fields are not initialized with the same value. This sometimes causes a java.util.zip.ZipException.
This issue has been fixed in R28.0.1.
Bug 9672130
Sometimes, calling java.lang.util.zip.Deflater.deflateBytes() after calling java.lang.util.zip.Deflater.end() causes the JVM to crash.
This issue has been fixed in R28.0.1 to throw a NullPointerException.
Bug 9459003
Sometimes, a method invocation with more than eleven arguments introduces undeterministic behavior in Java applications on x86_64 machines.
This issue has been fixed in R28.0.1.
Bug 9651960
The JRockit JVM spins forever when compiling JavaFX classes that contain endless loops.
This issue has been fixed in R28.0.1.
Bug 9616739
Some descriptions for the GcCompaction JFR event are not intuitive.
This issue has been fixed in R28.0.1.
The following issues have been fixed in Oracle JRockit JDK R28.0.0.
Bug 8816217
Inner type checks on arrays used to show the wrong type in optimized code. This issue has been resolved.
This release adds a workaround for deadlocks on the Windows platform when thread(s) block on I/O operations on any standard stream (stdin, stdout stderr/System.in, System.out, System.err) while a shared library (DLL) is loading. The deadlock occurs if a process is launched such that the stream on which a call is blocked is a redirected pipe, typically the result of either a spawned process through Process.exec or similar; or launched through a shell with data piped to or from itself. The bug happens because any I/O operation on such a pipe holds a kernel lock during the whole call, a lock which is also required by the WinAPI function GetFileType(). This function in turn is called from the Microsoft CRT startup code whenever either a new CRT DLL, or a DLL with statically linked CRT functions, is loaded.
The bug only occurs on Windows releases prior to Windows Vista.
Workaround
Detect whenever the JVM process is started with its stdin redirected to a pipe. Then intercept all FileInputStream.read() calls to it and prevent them from blocking, essentially doing polling I/O. The workaround prevents a thread reading from System.in from blocking any System.loadLibrary calls. This workaround might add some latency to reading from System.in, but should be invisible for most applications.
This workaround can be controlled by using these diagnostic options (unlock using -XX:+UnlockDiagnosticVMOptions):
-XX:+|-UseStdinPipeReadWorkaround, which enables the workaround (default is on).
-XX:StdinPipeReadWorkaroundPollPeriod=<millis>, which polls the period for reads from stdin (default 1)
Notes:
This fix does not handle NIO reads from System.in. Using these might still cause deadlocks of the JVM.
This fix is only activated if redirection of standard in is detected.
This release resolves the following issues, which arose when using the nondefault flag, -XXcallProfiling in Oracle JRockit R27.x.
Deadlock between compiler and code garbage collection.
Memory leak of call profiling data from invalidated methods.
This release fixes the issue of slow performance on Windows machines running with many (more than 40) processes with the same name whenever access was needed to the process PDH header or slow startup when running with the JRockit Flight Recorder.
The Oracle JRockit optimizing compiler was, in rare cases, producing erroneous results from computations that included a narrowing of primitive types. This issue has been fixed.
The broken Java launcher java-rmi.exe in JRockit 6 on Windows is no longer shipped with the product. See also Sun Bug 6512052 at:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512052