Skip Headers
Oracle® JRockit JDK Release Notes
Release R28

Go to Table of Contents
Go to Feedback page
Contact Us

Go to previous page
Go to next page
PDF · Mobi · ePub

3 Issues Resolved in Oracle JRockit JDK R28

This chapter lists the issues resolved in Oracle JRockit JDK R28.

It contains the following sections:

3.1 Issues Resolved in R28.3.12

The following issues have been fixed in Oracle JRockit JDK R28.3.12:

3.1.1 Hashtable Deserialization Reconstitutes Table with Wrong Capacity

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.

3.2 Issues Resolved in R28.3.11

The following issues have been fixed in Oracle JRockit JDK R28.3.11:

3.2.1 Corrupted Heap Data Resulting in Stability Issues

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.

3.2.2 Incorrect Value for Dark Matter Reported by Heap Diagnostics

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.

3.2.3 Incorrect Heap Statistics When Instances of a Class Consume Over 2 GB of Heap Space

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.

3.2.4 Hardware Support for Square Root on SPARC T2

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.

3.2.5 Default Number of Garbage Collection Worker Threads on Certain Solaris Systems

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

3.2.6 JVM Crashes when Using Application Data Integrity Features

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.

3.2.7 Unexpected Behavior when Copying Arrays

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.

3.3 Issues Resolved in R28.3.10

The following issues have been fixed in Oracle JRockit JDK R28.3.10:

3.3.1 Crash while Running Finalizer for the ConstPoolWrapper Object

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.

3.3.2 Crash due to Incorrectly Compiled (JIT) checkcast Operation

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.

3.3.3 Unexpected Behavior when Inlining a Method

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.

3.4 Issues Resolved in R28.3.9

The following issues have been fixed in Oracle JRockit JDK R28.3.9:

3.4.1 Issues with the ObjectStreamClass.lookup Method

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.

3.4.2 Process Hangs after NewStringUTF Invocation

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.

3.5 Issues Resolved in R28.3.8

The following issues have been fixed in Oracle JRockit JDK R28.3.8:

3.5.1 Incorrect CPU Consumption Values on Linux

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.

3.5.2 Unexpected NoSuchMethodError in JRockit JVM

In extreme cases, the reference count on a JVM internal string could overflow, which could result in internal string comparisons failing. This internal failure could result in a NoSuchMethodError and possibly other errors. This issue has been resolved.

3.6 Issues Resolved in R28.3.6

The following issues have been fixed in Oracle JRockit JDK R28.3.6:

3.6.1 JRockit JVM Crashes while Debugging a Java Program Compiled with javac

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.

3.6.2 JVM Crashes while Using an Agent

Previous versions of JRockit may crash or experience other stability issues after redefining a class at runtime by using the JVM Tool Interface (JVM TI) or by using the java.lang.instrument interface (-javaagent startup parameter).

This issue has been resolved.

3.7 Issues Resolved in R28.3.5

The following issues have been fixed in Oracle JRockit JDK R28.3.5:

3.7.1 Issue with Profiling Methods

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.

3.7.2 JVM Crashes with Illegal Memory Access Error Due to an Optimization Issue

Fixed an issue where JRockit would crash due to bad code optimization when using StringBuffer/StringBuilder in a loop. This issue only happened when running with compressed references.

3.8 Issues Resolved in R28.3.4

The following issues have been fixed in Oracle JRockit JDK R28.3.4:

3.8.1 Reduced Memory Footprint of Command-line Tools

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.

3.8.2 JRockit Crashes while Calling jrockit.vm.ArrayCopy.copy Methods

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.

3.9 Issues Resolved in R28.3.2

The following issues have been fixed in Oracle JRockit JDK R28.3.2:

3.9.1 Issue with Flight Recording During Startup

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 Oracle JRockit Command-Line Reference.

This issue has been resolved.

3.9.2 Check Stacks Option on SPARC Platform

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.

3.9.3 Unexpected NullPointerException Thrown from Methods After Code Optimization

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.

3.10 Issues Resolved in R28.3.1

The following issue has been fixed in Oracle JRockit JDK R28.3.1.

3.10.1 FileNotFoundException Thrown while Opening Zip Archives

JRockit did not recognize multibyte characters and hence a FileNotFoundException was thrown while opening a zip archive that has a UTF8 encoded filename.

This issue has been resolved.

3.11 Issues Resolved in R28.2.9

The following issues have been fixed in Oracle JRockit JDK R28.2.9:

3.11.1 Heap Dumps Not Generated on Out Of Memory Error

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.

3.11.2 Issue with the Out of Memory Error Message

In previous versions of JRockit R28, a native OutOfMemoryError message may indicate an incorrect value for the failed allocation size.

This issue has been resolved.

3.12 Issues Resolved in R28.2.8

The following issues have been fixed in Oracle JRockit JDK R28.2.8:

3.12.1 NullPointerExceptions from Package.getPackages Calls

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.

3.12.2 NullPointerExceptions from Class.isAssignable

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.

3.12.3 JRockit Crashes while Code Optimization in cgGetColorForVarInBlock

In certain cases, JRockit could crash during code optimization in the cgGetColorForVarInBlock method. This issue has been resolved.

3.13 Issues Resolved in R28.2.6

The following issues have been fixed in Oracle JRockit JDK R28.2.6:

3.13.1 JRockit Fight Recorder Repository Growing Indefinitely

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.

3.13.2 Unexpected Errors from Applications with Dynamically-created Classes

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.

3.13.3 JMXMAPI Profiling API Can Now Profile All Versions of a Class

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).

3.14 Issues Resolved in R28.2.5

The following issues have been fixed in Oracle JRockit JDK R28.2.5:

3.14.1 JRockit Crashes when Interned Strings are Allocated

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.

3.14.2 JRockit Crashes while Running with an optfile

In rare conditions, the JRockit JVM would crash if compiler directives are used in an optfile. This issue has been fixed.

3.14.3 FileNotFoundException Thrown while Reading Files from FileInputStream

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.

3.14.4 Issue while Closing a NIO Socket

Under certain circumstances, JRockit would hang while closing a NIO Socket. This issue has been fixed.

3.14.5 NIO Operations Fail on Windows with a Security Exception

When a SecurityManager is used on Windows, certain NIO operations used to fail with an AccessControlException. This issue has been fixed.

3.14.6 Wrong Exception Thrown when Flight Recorder is Disabled

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.

3.14.7 JRockit Crashes while Invoking a Method

JRockit crashes with illegal memory access in long [][] ids) method due to incomplete implementation of extensions.

The array version of ThreadMXBean.getThreadCpuTime() has been implemented in Oracle JRockit R28.2.5. The issue has been resolved.

3.15 Issues Resolved in R28.2.4

The following issues have been fixed in Oracle JRockit JDK R28.2.4:

3.15.1 Issue with the jrcmd Command File Parsing

A regression was introduced in JRockit R28.2.3 where the "stop" statement was ignored by the jrcmd command. This issue has been fixed.

3.15.2 Failure to Start on Solaris While Using a Large Page Size

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.

3.15.3 Issue with print_memusage Diagnostic Command

An invalid value for the level argument of the print_memusage command could cause the target JVM to exit with an assertion error.

This issue has been fixed in R28.2.4. An error message is displayed and there is no impact to the target JVM.

3.16 Issues Resolved in R28.2.3

The following issues have been fixed in Oracle JRockit JDK R28.2.3:

3.16.1 Redirecting Ouput of the jrcmd Command to a Specified File

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 Oracle JRockit Command-Line Reference.

3.16.2 Issue with the Limited File Size for the jrcmd Script File

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.

3.16.3 Issue while Reserving VMSpace

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.

3.16.4 Improved Stack Overflow Handling

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.

3.16.5 Issue while Optimizing a Method

Under rare circumstances, JRockit would crash when optimizing a method, often a method in the java/util/regex package. This issue has been fixed.

3.16.6 Issue with JRockit after Removing JRockit Flight Recorder

If the Flight Recorder repository was deleted from the hard drive while JRockit was running, the process would hang indefinitely. This issue has been fixed.

3.17 Issues Resolved in R28.2.2

The following issues have been fixed in Oracle JRockit JDK R28.2.2:

3.17.1 Exceptions are Thrown while Establishing SSL Connections that use Cipher Suite

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.

3.17.2 Issue with Code Optimization

A bug in string append optimization could lead to a crash in JRockit JVM, often during garbage collection. This issue has been fixed.

3.17.3 Missing Finalizers

In JRockit versions R28.0.0 through R28.2.1, some finalizers may never be called. Because JRockit uses finalizers internally to manage class constant pool data, this could cause data corruption resulting in JVM crashes and other unspecified behavior. This issue has been fixed.

3.18 Issues Resolved in R28.1.5

The following issues have been fixed in Oracle JRockit JDK R28.1.5:

3.18.1 Unable to Reserve Memory in the Low Address Space of the Java Heap

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

3.18.2 Thread Starvation while Using the Default Number of Garbage Collection Threads in Multi-Core Machines

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.

3.18.3 Error while Setting SUID or SGID on JRockit JVM

The effective user was not same as the real user if you had set SUID or SGID on the Java library. The JRockit JVM failed to start.

This issue has been fixed.

3.19 Issues Resolved in R28.1.4

The following issues have been fixed in Oracle JRockit JDK R28.1.4:

3.19.1 Warnings Print When Launching Java Involving Symbolic Links on Windows

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.

3.19.2 Corrupt HPROF File

When Oracle JRockit was configured to dump an HPROF on an OutOfMemoryError and was receiving multiple simultaneous OutOfMemoryErrors in multiple threads, the resulting HPROF file might have been corrupt. This has been fixed.

3.20 Issues Resolved in R28.1.3

The following issues have been fixed in Oracle JRockit JDK R28.1.3:

3.20.1 Deadlock Occurring in the ClassLoader (Sun Bug 7001933)

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.

3.20.2 "Peer Not Authenticated" Exception Unexpectedly Thrown (Sun Bug 6924489)

The exception peer not authenticated was unexpectedly being thrown. This has been fixed; this fix resolves Sun Bug 6924489.

3.20.3 Problem Setting SO_RCVBUF/SO_SNDBUF (Sun Bug 6984182)

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.

3.20.4 Passing Read-Only Bytebuffer to Channel Write Method Throwing Exception

Passing a read-only bytebuffer to a channel write method could throw a java.nio.ReadOnlyByteBufferException. This has been fixed.

3.20.5 Specific JNI API Routines Did Not Correctly Set isCopy Parameter

JNI API Get<PrimitiveType>ArrayElements routines did not correctly set isCopy parameter to JNI_TRUE when returning copies. This has been fixed.

3.20.6 Incorrectly Optimized Methods Forcing Long Values to Become Very Large

In rare circumstances, on instances of 32-bit JRockit, a method could be incorrectly optimized forcing long values that should be 0 to become very large. This has been fixed.

3.21 Issues Resolved in R28.1.1

The following issues have been fixed in Oracle JRockit JDK R28.1.1:

3.21.1 Crashes During Concurrent Sweep JNI Object Allocation

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.

3.21.2 Silent Exit When Command-Line Options are Misspelled

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.

3.21.3 Erroneous Optimization of an arraycopy

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.

3.21.4 JDK Read Fixed Number of Bytes When Calling SecureRandom.generateSeed

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:

3.21.5 instanceof Check Failing

Occasionally, the optimizer would erroneously change the behavior of an instanceof opcode, causing the instanceof check to fail. This has been fixed.

3.22 Issues Resolved in R28.1.0

The following issues have been fixed in Oracle JRockit JDK R28.1.0:

3.22.1 Oracle JRockit Hangs when used with Application Management Solutions

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.

3.22.2 Memory Leakage in the JMX Implementation

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.

3.22.3 Oracle JRockit Exits when Aborting an Optimization

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.

3.22.4 Oracle JRockit Heap Dumps Do Not Open in Eclipse Memory Analyzer

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.

3.22.5 Exceptions Thrown Without InvocationTargetException Wrapping

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.

3.23 Issues Resolved in R28.0.2

The following issues have been fixed in Oracle JRockit JDK R28.0.2:

3.23.1 Oracle JRockit Starts Slowly on Some Solaris Machines

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.

3.23.2 IO Exceptions in Epoll Socket Muxer Would Throw NoClassDefFoundErrors

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.

3.23.3 Oracle JRockit Crashing While Pruning References to Obsoleted Code

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.

3.23.4 Oracle JRockit Could Not Open JAR or ZIP Files Larger Than 2GB

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.

3.23.5 Xalan and Xerces Versions Updated

The Xalan and Xerces versions were updated to fix a functional regression found in JDK 1.6.0_18. This fix is included in the Oracle JRockit R28.0.2 JVM.

3.24 Issues Resolved in R28.0.1

The following issues have been fixed in Oracle JRockit JDK R28.0.1.

3.24.1 JVM Crashes on Encountering Non-UTF8 Characters in Compiler Directives

The JVM crashes when it encounters non-UTF8 characters in a compiler control directives file.

This issue has been fixed in R28.0.1.

3.24.2 Null-Check Incorrectly Optimized or Proved as Always Failing

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.

3.24.3 Linux Systems Crash at Startup when is Set to be Preloaded

On Linux systems, the JVM crashes at startup if the user sets (the signal chaining library) to be preloaded through the 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.

3.24.4 NIO Selector Functionality Failure

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.

3.24.5 Deprecated Flag -XXExternalCompactRatio Gives Incorrect Warning

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.

3.24.6 ZipEntry Initialization Error

When the 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

This issue has been fixed in R28.0.1.

3.24.7 Crash in ZLIB Code While Running Finalizer

Sometimes, calling after calling causes the JVM to crash.

This issue has been fixed in R28.0.1 to throw a NullPointerException.

3.24.8 Undeterministic Behavior on x86_64 Machines

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.

3.24.9 JVM Spins Forever When Compiling JavaFX Classes

The JRockit JVM spins forever when compiling JavaFX classes that contain endless loops.

This issue has been fixed in R28.0.1.

3.24.10 Descriptions Not Intuitive for Compaction JFR Events

Some descriptions for the GcCompaction JFR event are not intuitive.

This issue has been fixed in R28.0.1.

3.24.11 WLS NIOSocketMuxer Occasionally Loses Sockets On Windows

At times, sockets disappear when the NIOSocketMuxer is used with WebLogic Server running on Windows.

This issue has been fixed in R28.0.1.

3.25 Issues Resolved in R28.0.0

The following issues have been fixed in Oracle JRockit JDK R28.0.0.

3.25.1 ACopyRemoval Breaks Explicit Typechecks

Inner type checks on arrays used to show the wrong type in optimized code. This issue has been resolved.

3.25.2 Deadlocks On the Windows Platform When Threads Block on I/O Operations

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.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.


Detect whenever the JVM process is started with its stdin redirected to a pipe. Then intercept all calls to it and prevent them from blocking, essentially doing polling I/O. The workaround prevents a thread reading from from blocking any System.loadLibrary calls. This workaround might add some latency to reading from, 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)


  • This fix does not handle NIO reads from Using these might still cause deadlocks of the JVM.

  • This fix is only activated if redirection of standard in is detected.

3.25.3 Issues with Nondefault Flag with -XXcallProfiling in Oracle JRockit R27.x

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.

3.25.4 Performance Issues with Windows Computers Running Many Processes

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.

3.25.5 Optimizing Compiler Producing Erroneous Results

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.

3.25.6 Broken Java Launcher Removed from Product

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:


Oracle JRockit R27.6.0 was not posting the JVMTI_EVENT_COMPILED_METHOD_UNLOAD event when unloading obsolete method code. This issue has been fixed.