java.math.BigDecimal Objects Cannot be Serialized Over IIOP Between Releases
Timing Stability Issue When "Fast Time" Is Enabled on Intel Systems
JMAPI Method Changed to Throw an UnapplicableMethodException
Error Message for CPU Load Counters for JRockit JVM Running on Windows
SSE2 Registers Might Not be Restored Correctly After Return from Signal Handler
System Crashing when Stack Expansion Uses Randomized Address Spaces
Calculation-Intensive Applications Returning Corrupt Register Values
R28 Not Supported On Windows 2008 With More Than 64 Processors
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.
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.
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.
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 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 http://download.microsoft.com/download/win2000platform/exctrlst/1.00.0.1/nt5/en-us/exctrlst_setup.exe.
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-78.0.13.0.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).
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.
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.
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.
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.
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.
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).
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.
security-libs/javax.net.ssl
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