Skip Headers
Oracle® JRockit JDK Release Notes
Release R28

Go to Table of Contents
Go to Feedback page
Contact Us

Go to previous page
PDF · Mobi · ePub

4 Known Issues in Oracle JRockit JDK R28

This chapter describes issues known to exist in the Oracle JRockit JDK R28.

Issue with Object Initialization in JRockit

The JRockit JVM 1.6.0 registers finalizeable objects when an object is allocated.

The Java Language Specification (JLS) necessitates objects to be registered only after the <init> method of the java.lang.Object class has been run and completed successfully.

Issues while Using 64-Bit Compressed References on SPARC

The JRockit JVM might crash if you use 64-bit compressed references on SPARC platform.


Specify a lower size for the compressed references by using the option -XXcompressedRefs:size=4GB. If the problem persists, disable the compressed references by specifying the option -XXcompressedRefs:enable=false.

Alternatively, you can change the value of -Xmx option to a value less than 3 GB.

For more information about the -XXcompressedRefs and -Xmx options, see Oracle JRockit Command-Line Reference.

Limited Amount of Active Monitors

If a Java program uses too many (4,194,304) active monitors (that is, by doing wait/notify or contended synchronization on too many objects) the JVM's internal monitor index can overflow. This is more likely to happen when using large heaps and few garbage collections occur. If this happens, the JVM will crash with an error saying "The number of active Object monitors has overflowed."

Error While Using print_utf8pool Command on Windows

The jrcmd command print_utf8pool, that prints all UTF8 strings, fails to handle unicode characters correctly on Windows platform.

HPROF Heap Dump Might be Corrupt When Multiple OOMs Thrown

If Oracle JRockit encounters several Java Out of Memory exceptions while writing an HPROF heap dump, the contents of the heap dump might be corrupt.

java.math.BigDecimal Objects Cannot be Serialized Over IIOP Between Releases

Serialization of java.math.BigDecimal objects over IIOP between the JRockit JVM and other JVMs throws an IOException. This incompatibility has been fixed; the JRockit JVM R28 is now compatible with other JVMs but not with older R27 releases. As a consequence, java.math.BigDecimal objects cannot be serialized over IIOP between the R27 and R28 releases of the JRockit JVM.

Timing Stability Issue When "Fast Time" Is Enabled on Intel Systems

Timing stability issues might occur on modern x86 systems (for instance Nehalem-EX) with more than two CPU sockets.

Disabling fast time (by using the -XX:-UseFastTime command-line option) could solve the issue.

JMAPI Method Changed to Throw an UnapplicableMethodException

In R28.0 the JMAPI method com.bea.jvm.ProfilingSystem.newConstructorProfileEntry() was changed to throw an UnapplicableMethodException. This exception is never thrown in practice but the addition causes compilation errors for old code. Removing the exception declaration will also cause problems compilation, thus the exception will remain in future versions.

Error Message for CPU Load Counters for JRockit JVM Running on Windows

At times, the following message might be displayed when running the JRockit JVM on Windows.

[WARN ][osal   ] could not enumerate processors (1) error=-1073738824
[WARN ][osal   ] Failed to init system load counters

This issue occurs when the Windows processor performance counter (PerfOS) is disabled.

The message also indicates that CPU load events are not recorded in JRockit Flight Recorder and not shown in the JRockit Mission Control console.

Workaround: Enable the PerfOS counter in Windows by using the Microsoft Extensible Counter List tool (exctrlst.exe). You can download the tool from

Oracle JRockit Hangs On OEL/OVM Combination

When Oracle JRockit is running on OEL on OVM, a fix is required in OEL. Listed below are the minimum requirements for running JRockit on OEL on OVM:

  • OVM 2.1.2

  • OEL 4.7 ia32

    Patch required. The version of the para-virtualized kernel for OEL must be 2.6.9- or later.

  • OEL 4.7 x64

    GA bits works fine

  • OEL 5.3 ia32 and x64

    GA bits works fine

Oracle JRockit supports both hardware and para-virtualized versions and both OEL 4 and OEL 5.

Triggering Young Collections if the Nursery is Too Small

If the nursery is too small, Oracle JRockit might begin triggering young collections, “back to back", without promoting anything. This appears in the -Xverbose:memdbg output as repeated young collections where the number of promoted objects is zero. It can also be seen as very short times between the young collections (close to 0 ms).


Increase the nursery size. If nursery size has been set automatically by -Xgcprio:throughput, it can be overridden by manually setting -Xns to a higher value.

SSE2 Registers Might Not be Restored Correctly After Return from Signal Handler

Due to a Linux kernel bug, certain SSE2 registers might not be restored correctly after returning from a signal handler. This issue manifests itself as such undefined behavior as erroneous floating values in Java code and crashes.


This problem is fixed in mainline kernel version 2.6.xx. You can obtain patches for OEL 4 and OEL 5 as RPM'S from the Unbreakable Linux Network. Follow normal kernel upgrade procedure to obtain the fix.

For older kernels, use the command-line option -XX:+UseMembarForTransitions.

System Crashing when Stack Expansion Uses Randomized Address Spaces

On some newer Linux systems (for example, SLES 11) you might experience crashes related to stack expansion when using randomized address spaces.


In Linux, you might be able to eliminate these crashes by using the kernel configuration command sysctl -w kernel.randomize_va_space=0.

In Oracle JRockit, you can eliminate these crashes by using the JVM command-line option -XX:+TrustPThreadStackInfo. The flag defaults to false.

Large Pages on Solaris Might Cause Long Pauses

Using large pages on Solaris might occasionally cause long pauses. These pauses happen when a page is accessed for the first time.


Disable large pages by using the command-line option -XX:-UseLargePagesForHeap.

Calculation-Intensive Applications Returning Corrupt Register Values

Floating point calculation-intensive programs run on top of the Oracle JRockit JVM might result in bogus results. This happens because a bug in the Linux kernel does not preserve some CPU registers when switching between tasks. Oracle makes a patch available for OEL 4 and 5. For OEL 4 you need OEL 4.8 with updated kernel (2.6.9- or later). For OEL 5 you need an updated kernel (2.6.18- or later). The fix is included in OEL 5.5. Novell also makes a fix available (BugZilla number 573478). The fix is available for SLES 9 SP4; SLES 10 SP2 and SP3; and SLES 11. The issue has also been reported to RedHat (BugZilla number 547893). Contact RedHat support for access to this fix.

R28 Not Supported On Windows 2008 With More Than 64 Processors

Oracle JRockit does not support more than 64 logical processors on Windows Server 2008 and Windows Server 2008 R2.

Out of Memory Error Occurs When Classblock Memory Runs Low

On Solaris/SPARC, due to the way classblock memory is reserved, Oracle JRockit might occasionally run out of memory when a large number of classes are loaded (in the order of 100000).


Use the following command-line options:

-XX:+UnlockDiagnosticVMOptions  -XX:MaxClassBlockMemory=xxM

The default value of -XX:MaxClassBlockMemory is 50 MB, and a reasonable value is around 75 MB.

IllegalArgumentException from TLS handshake


A recent issue from the JDK-8148516 fix can cause issue to 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 does not 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

See JDK-8148516