Skip navigation.

Release Notes

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

BEA JRockit 5.0 JDK Release Notes

Version 5.0 (R25.2) JDK

This document contains important details for BEA JRockit 5.0 (R25.2) JDK. It contains information on the following subjects:


License Agreement

The BEA JRockit 5.0 (R25.2) JDK is subject to the terms and conditions of the BEA JRockit Binary License Agreement.


Platform Support


Java Support



BEA JRockit JDK is available as a standalone application. For instructions on installing BEA JRockit, please see Installing BEA JRockit JDK.


Other Documentation

This release of BEA JRockit JDK includes a complete documentation set comprised of these documents:

Copies of all BEA JRockit documents can be found at:


Most Recent Changes

Below you find information about the most recent changes of BEA JRockit.

Changes in JRockit 5.0 (R25.2)

The following CRs have been corrected for this release.

Change Request ID



Looking at allocation stacktraces in the Memory Leak Detector could show stacktraces where the selected type was not allocated, as well as stacktraces where it was allocated. This has been fixed.


An issue that prevented the Java Plugin from running applets in Internet Explorer is solved in this version. JRockit 5.0 will now run applets in Internet Explorer.


Under high network load, JRockit could sometimes incorrectly throw exceptions of the type " Socket closed." This has now been fixed.


Options that are not valid JRockit options, have sometimes been parsed as a different, valid option. This happened if the valid option began with the same characters as the invalid one. For example, -Xcheck could be parsed as -XcheckedStacks. This problem is now fixed.

CR204924 now returns -1 at end of file instead of throwing an exception.


Calling Object.wait() in a system with high lock contention could cause JRockit to throw a NullPointException. This has now been fixed.


The Memory Leak Detector now lists the top 10 items (if applicable) when listing the largest arrays.


The JRockit Analyzer (JRA) does not crash the JVM anymore when the JVM runs with the gencon garbage collector.


The garbage collector MXBean method getNurserySize does not throw an internal RuntimeException anymore when a nursery is not available.


JRockit will no longer crash when installed as a web browser plugin and you press "v" in the Java Console.


Hour-glass does not stay on the screen in Management Console anymore.


JRockit issues events on multiple threads during garbage collection. New option, -Xjvmpi:singlegc=true, has been added to force events being issued via one thread only.


JRockit memory usage has been improved in cases where there are many classloaders with few classes per classloader.


User defined actions in the Management Console are now working.


JRockit startup time has been improved.


Stack overflow issues are now handled more safely.


Previously JRockit displayed incorrect nursery size information when using -Xverbose:memory with an optimizing garbage collector. This information is no longer displayed.


The optimizing compiler could generate inaccurate code for This problem is now fixed.


A race condition that could lead to a null pointer exception when generating the detail panes in the Management Console is now eliminated.


Prevent applications from changing the private field parent in java.lang.ClassLoader.


Can now create arrays larger than 256*1024*1024 elements.


The MemoryMBean attribute ObjectPendingFinalizationCount now returns the correct value.


On 64-bit platforms, JRockit could crash if the Memory Leak Detector tried to retrieve the largest arrays for a type. This has now been fixed.


When using IterateOverReachableObjects in JVMTI, JRockit reported bad referrer_index for JVMTI_REFERENCE_FIELD. This has now been fixed.


Reverted the java.vendor* system properties back to BEA specific property values.


Eliminated sporadic deadlocks on platforms with weak memory guarantees.


Previously JRockit could crash during shutdown, possibly without generating either a crash dump or a core file. This was an uncommon problem, but has now been fixed.

Changes in JRockit 5.0 (R25.1)

The following CRs have been corrected for this release.

Change Request ID



CGLIB does not throw IllegalAccessError.


JRockit on x64 may crash due to a floating point code generation bug. This is now fixed.


Overriding package local final Methods now works.

CR211961 property now exists.


When iterating over stack frames, getStackAccessControlContext used the wrong iterator (frame instead of call), which could result in JRockit missing optimized frames.


Throwing ZipException instead of IOException when encountering empty or invalid zipfile


System.arraycopy had an off-by-one error with short-arrays when doing a reverse copy. This is now fixed.


lphello does not dump in cgGetCallChainOnAddr.


Large page for IA32 Linux with 2.6 kernels are now working.


Problems with method resolving in JNI now fixed.


WebLogic Enterprise Platform arraycopy might read outside of heap on X86. This issue is now fixed.


JRockit is now able to throw ClassCircularityError.


Optimizing problems causing a thread dump, sometimes occurring with optimizeIt, now fixed.


Heap/object allocation scaling bottleneck solved by modifying -XXaggressive to set the cachelistpercentage to 10% and by adding jrockit.heap.cachelistpercentage property. This sets the percentage of free heap memory that will be kept in the freelist caches that are used for speeding up object allocation (for example set: -Djrockit.heap.cachelistpercentage=15 on the command line to set the percentage to 15%).


JRockit dump in zipReleaseEntry during adminServer (WLS) startup, R25.1.0-96. This is a known issue in a third-party product used by BEA JRockit.


Rare "timeout" with gencon showed out to be an internal signal error. This is now fixed.


In the BEA Installer the Java Control Panel is now installed.


If JRockit is uninstalled and thereafter reinstalled, the installer fails to set JRockit as a plugin to any browser. This problem has now been fixed.


BEA Installer: Multiple instances of JRockit installation problem has been fixed.


If user installs JRockit in another location than the default location, the Registry keys still point to the default location (which do not exist). This problem is now fixed.


JRockit does not fail to install Java Web Start anymore.


Java Application Cache Viewer can now be launched from bin as well as jre/bin.


Internet Explorer is now shown as a browser alternative.


Support for profiling of VM internal locks are now implemented.


External system properties handling is now cleaned up.


sun.reflect.ReflectionFactory.newConstructorForSerialization does not work.

Note: JRockit does not support that API.


IPF largepages MAP_PRIVATE is now supported.


Invocation compiler newInstance now generates call to registerfinalizer.


Performance degradation over time with -Xgcprio:throughput due to incorrect strategy choice. Heuristics updated and no degradation can be observed.


JRockit crashed when starting a server with OptimizeIt due to differences between the handling of startEvents in JVMTI and JVMPI. This is now fixed.


Optimistically enable HT optimizations if processor supports it but OS cannot confirm.

To enable the optimistic approach, the property has been added.


JRockit now returns the class with the most specific return type from Class#getDeclaredMethod when several matching methods are found.


JRockit VM seems to hang when attaching optimizeIt and trying to deploy a client. OptimizeIt uses getthreadstate frequently. The implementation of that method used to suspend native threads to retrieve information. Now JRockit does not need to suspend native threads when retrieving their status.


ClassFormatError with resin 3.0.10. Now allows multiple LocalVar*Table:s in any order.


StackOverFlowError while viewing JRA profile has been fixed.


Bytecode verification is now less strict to be compliant with the reference VM.


Potential deadlock in JVMTI/rawmonitors when using gcevents has been eliminated.


During shut-down, JRockit crashed when failing to acquire shared memory. This is now fixed.


GetLineNumberTable now returns JVMTI_ERROR_NATIVE_METHOD in case of native methods.


Upgrade to 1.5.0_02: Instances of java.lang.Enum are now never finalized, Sun bug 5098065.


Fixed race condition in add_JVMPI_entryexit_hooks.


JRockit can now bootstrap when launched from UNC path.


Fixed ObjectMonitor memory leak.


JRA now samples even if started with -Xnoopt.


Out of memory error even though heap could still be expanded. Now heap expansion has been corrected.


Missing JNI support, like JAWT, is now added.


File handle leak in on directories is now fixed.


JRockit max heap size on win_ia32 can now increase beyond 1574304kb with /3GB parameter in boot entry.


Fixed rapid increase of heap usage after IllegalMonitorStateException.


Starting JRockit with the option -Xcleartype has no effect. The option is now deprecated and may be removed in a future release.


The jvmtiGetTag now works.


JVMTI now reports JVMTI_HEAP_ROOT_THREAD to the correct callback in iterateover objects.


Can now add static initializer to Object.


Remote JMX using authentication, file + password, now works.


Eclipse dumps when running on JRockit. This problem is now solved.


JRockit does not hang anymore when trying to throw StackOverflowError.


jrcmd now resolves path to JRockit executable correctly.


JRockit now supports the -Xrs option.


Large unused nursery and still getting an out of memory error. This problem has now been fixed.


Eternal garbage collection if an application stores too many finished threads. This has now been fixed and JRockit will not collect garbage eternally.


JGCW does no longer expose problems with finalizers.


The name of the -XXhpc option has changed to -XXhpm due to confusion with industry acronym for "high performance computing."


No more npe when adding StringBuffer.append(char[]) to method profiling.


Management Console does not deadlock anymore when reconnecting to a new VM.


Warn if the host computer swaps during collection. If verbose:memory is turned on, JRockit now warns if the total number of page faults during garbage collection is bigger than 5% of the number of pages in the heap.


fix_javahome, realpath, and symlinks cause java.home to be incorrect.

In this release, JRockit handles longer realpaths from symlink to java.home, which corrects this problem.


Previously JRockit missed to report some compile_method_events. This is no longer the case.


JRockit can only allocate 1500m heap on Windows 2003 IA32. The JVM performance counters are now initialized after the heap is allocated, which corrects this problem.


Occasional JRockit crash when starting a JRA recording has now been fixed.


The initialization behavior and value of sun.boot.class.path differs between JRockit and Sun. The initialization behavior has now been rewritten to mirror the behavior of Sun.


Getting threads by name from MAPI now works.


Cannot build update-site in Eclipse.


Counter for encountered deadlocks added.


The Management Console now shows deadlock detection data in thread stack dumps.


Parts of JVMTI system properties interface implementation now follow the specification.


A table is added for native lock profiling on the JRA's Lock Profiling page.


Features, Changes, and Enhancements

Below are new features, changes, and enhancements for each release listed.

BEA JRockit 5.0 (R25.2)

BEA JRockit 5.0 (R25.1)

BEA JRockit 5.0 (R25.0)


Known Issues

The following issues are known in the BEA JRockit 5.0 release:



Australian Daylight Savings Time change for 2006 not supported.

This release does not contain a fix for the Australian Daylight Savings Time change for 2006. Please contact BEA Support for a patch.

JRockit crashes when using a heap larger than 5375 MB on Red Hat 4.0 for EM64T/AMD64.

You can workaround this problem by using a heap smaller than 5375 MB.

This will be fixed in the next service pack (CR247853).

A signal being sent to wrong thread on Linux 2.6 kernels on Itanium (2.6.11 and previous Itanium kernels) might cause random hanging or crashing JVM.

BEA JRockit is known to hang or crash on 2.6 kernels on Itanium, due to a bug in the Linux 2.6.11 (and previous) kernels. The bug is in the kernel sigprocmask() syscall and will be fixed in the 2.6.12 kernel.

We cannot estimate how often the bug actually occurs, but under different circumstances it has been seen as often as once per hour or as seldom as once every two days.

BEA believes that this issue affects SMP systems more than single CPU systems.

Affected Linux versions are: SuSE Linux Enterprise Server 9.0 and RedHat Enterprise Linux 4.0 on Itanium running on 2.6.11 (or previous) kernels. (CR230226 and CR218035).

SuSE has confirmed that this bug will be fixed in their upcoming SLES 9.0 SP2 release. We are working with RedHat to get this fix into RHEL 4.0 Update 2.

You can see the committed patch at:

Customers running SMP systems must patch their kernel to include the kernel fix or upgrade to a newer kernel. At the time of our release (June 22, 2005) no offically updated kernels are available. If you are running on SLES 9.0 Itanium, you should upgrade to SP2 once it is made available.

The RedHat internal reference number is 74397. For SuSE the internal reference number is 78084.

BEA JRockit Memory Leak Detector hangs when displaying aquired instances.

The BEA JRockit Memory Leak Detector could in some instances cause JRockit to freeze or crash. (CR228592)

JRockit deadlock on SUSE Linux Enterprise Server 9.0 running on x64/SMP

There is a kernel bug in SUSE Linux Enterprise Server 9.0 x64 version, which causes signals to be lost on rare occations on multi-CPU systems. This is not noticable for most applications, but JRockit relies heavily on signalling, and is therefore affected by this bug. The consequence of the bug is that JRockit deadlocks. For this reason, it is *not recommended* to use JRockit for production on this platform, until this problem has been fixed by SUSE. BEA is working with SUSE to get the fix into the kernel.

Affected Linux version is SUSE Linux Enterprise Server 9.0 SP1. The problem is also present in RedHat Enterprise Linux 4.0 GA on x64, but it will be fixed in the upcoming RHEL 4.0 QU1. (CR230225 CR220658)

Crash in garbage collector under rare circumstances

JRockit may crash with an Illegal memory access and point to a problem in mmNurseryAddTLAsToCache. This is a timing dependent problem that might occur when run with a generational garbage collector. Low probability (CR229720).

Crashes in cbGetCodeInfoOnAddr

Under certain circumstances, JRockit can crash when unloading classes (CR229723).

JRockit may deadlock

If JRockit has been installed as a java plugin for a browser, pressing "v" (dump threads) in the Java Console has a high chance of causing JRockit to deadlock (CR225442)

demo\jpda trace example fails

This is because line numbers are not available for the classes in the jrockit.jar file (CR221291).

Corrupt or missing fonts or icons

When running AWT/java2d/java3d applications with JRockit, on certain configurations, the AWT DirectX acceleration might fail to initialize. This is due to virtual memory space conflicts.

Workaround: set an explicit -mx flag to approximately half the amount of the physical RAM or less.

Static field values are reset to zero/null.

Using dynamic code replace from a debugger will cause static field values to be reset to zero/null, and can also cause spurious crashes at a later time due to un-updated references to the old field values.

Workaround: do not redefine class definitions containing static fields

JRockit is crashing due to a signal handling conflict.

For Linux users only.

If you are using JRockit in conjunction with a native library that relies on OS signals you may experience crashes due to a signal handling conflict between JRockit and the native library.

Workaround: set the environment variable LD_PRELOAD as follows:

export LD_PRELOAD=$JROCKIT_HOME/jre/lib/i386/

BEA Engineering found this conflict using IBM's MQSeries native drivers, and it may be present in other libraries that rely on native code.

For more information, see


Back to Top Previous Next