Skip Headers
Oracle® JRockit JDK Release Notes
Release R28

Part Number E15066-28
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
PDF · Mobi · ePub

4 Known Issues in Oracle JRockit JDK R28

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

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

Running Java applications compiled with javac in debug mode might result in a JVM crash. This happens when you have specified -Xdebug or -XX:+JavaDebug option at the startup.

Workaround

Use the Eclipse compiler to compile applications in debug mode.

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

4.3 Issues while Using 64-Bit Compressed References on SPARC

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

Workaround

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.

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

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

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

4.7 JVM Crashing During GC When Running With -Xdebug or -agentlib:jdwp

Under some circumstances, Oracle JRockit might crash in the garbage collector when running with -Xdebug or -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.

Workaround:

Do not use -Xdebug or -agentlib:jdwp. The bug in javac will be fixed in an upcoming release of the JDK. If you have additional questions, contact Oracle Support.

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

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

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

4.11 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 http://download.microsoft.com/download/win2000platform/exctrlst/1.00.0.1/nt5/en-us/exctrlst_setup.exe.

4.12 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:

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

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

Workaround:

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.

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

Workaround:

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.

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

Workaround:

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.

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

Workaround:

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

4.17 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-89.0.18.0.1.EL or later). For OEL 5 you need an updated kernel (2.6.18-164.9.1.0.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.

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

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

Workaround:

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.