|Oracle® JRockit JDK Release Notes
Part Number E15066-29
|PDF · Mobi · ePub|
This chapter describes issues known to exist in the Oracle JRockit JDK R28.
Running Java applications compiled with
javac in debug mode might result in a JVM crash. This happens when you have specified
-XX:+JavaDebug option at the startup.
Use the Eclipse compiler to compile applications in debug mode.
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.
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
Alternatively, you can change the value of
-Xmx option to a value less than 3 GB.
For more information about the -
-Xmx options, see Oracle JRockit Command-Line Reference.
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.”
The jrcmd command
print_utf8pool, that prints all UTF8 strings, fails to handle unicode characters correctly on Windows platform.
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.
Under some circumstances, Oracle JRockit might crash in the garbage collector when running with
-agentlib:jdwp. When running in debugging mode, if variables are defined in a try-block and the JVM stops the thread at certain safepoints within the try/catch/finally block, the JVM will crash. The root cause for this problem is that some class files generated by Oracle javac contain incorrect debugging information, information the Oracle JRockit JVM depends on when stopping the threads.
Do not use
-agentlib:jdwp. The bug in javac will be fixed in an upcoming release of the JDK. If you have additional questions, contact Oracle Support.
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 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.
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.
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
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:
OEL 4.7 ia32
Patch required. The version of the para-virtualized kernel for OEL must be 2.6.9-126.96.36.199.1.1.ELxenU 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.
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.
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
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.
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
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-188.8.131.52.1.EL or later). For OEL 5 you need an updated kernel (2.6.18-184.108.40.206.1.el5 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.
Oracle JRockit does not support more than 64 logical processors on Windows Server 2008 and Windows Server 2008 R2.
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:
The default value of
-XX:MaxClassBlockMemory is 50 MB, and a reasonable value is around 75 MB.