BEA JRockit R26 JDK Release Notes

This document contains important details for BEA JRockit R26 JDK. It contains information on the following subjects:

License Agreement

The BEA JRockit R26 JDK is subject to the terms and conditions of the BEA JRockit Binary License Agreement, see the BEA License Agreement.

Platform Support

Java Support

Installation

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

Documentation Accompanying the BEA JRockit Release

The documentation that is connected to a specific release of BEA JRockit is located here:

New Features and Enhancements in BEA JRockit R26.4

BEA JRockit R26.4 provides, apart from full support for J2SE 5.0 on all supported platforms, the following areas of improvement:

Performance Improvements on 64-bit Platforms

Performance Improvements for Low Latency Applications

The performance of BEA JRockit has gone through major improvements for low latency applications by the following additions:

See Figure 3 for an illustration of how the performance have been improved with the above improvements.

Performance Improvements on SPARC

SPARC performance running BEA WebLogic Server has been improved by approximately 15% compared to BEA JRockit R26.3.

Additional Tuning Possibilities

For complete information on how to use all tuning options in BEA JRockit, please see the BEA JRockit Reference Manual.

New Features and Enhancements in BEA JRockit R26.3

New Features and Enhancements in BEA JRockit R26.2

New Features and Enhancements in BEA JRockit R26.1

New Features and Enhancements in BEA JRockit R26.0

Most Recent Changes

Changes in the BEA JRockit R26.4 Release

Change Request ID

Description

CR279188

When JRockit 1.4.2_10 R26.3 calculates the SUID for a class to be serialized it includes the synthetic bits in the calculation, which generates a SUID that differs from the Sun 1.4.2_10 and BEA JRockit 1.4.2_08 R24. This problem causes serialization to fail.

Synthetic attributes are included in a class when the class references a class pointer ATestClass.class or uses assertions.

This means that RMI communication between 1.4.2_10 R26.3 and Sun 1.4.2_10 can fail. RMI communication between BEA JRockit 1.4.2_10 R26.3 and BEA JRockit 1.4.2_08 R24.5 can also fail in the same way. Serialized classes, stored in a database, might also fail to be loaded.

Note:

This has been fixed in R26.4.

CR258122, CR258159, CR264680

The following new options have been added:

-XXgcTreads
-XXlazyUnlocking
-XXthroughputCompaction
-XXinternalCompactionMultiplier
-XXexternalCompactionMultiplier

For a description of these options, please see the BEA JRockit Reference Manual.

CR258934

New arguments have been added to enable control of large pages (-XXlargePages) on Solaris.

For a description of -XXlargePages, please see the BEA JRockit Reference Manual.

CR267987

Using java.nio.channels.SelectionKey.OP_CONNECT will make BEA JRockit block forever. This has now been fixed.

CR268133

Previously java.lang.reflect.Method.getParameterAnnotations() returned the wrong result for methods that did not have annotations. This has now been fixed.

CR268439

Previously when calling JVMTI functions from a non-attached thread caused BEA JRockit to crash. This has now been fixed.

CR269375

For each old collection, the reason for a garbage collection is printed in the verbose:memdbg.

CR271551

Previously buffers that had been allocated through ByteBuffer.allocateDirect() would not be released, even when discarded by the application, which caused C heap memory leaks. This has now been fixed.

CR272364

The JVMTI function GetThreadInfo returned an error if passed NULL as the thread. It now treats NULL as the current thread in accordance with the specification.

CR274636

Previously BEA JRockit 1.4.2 R26.2 and R26.3 threw a java.lang.NullPointerException when passing a null argument to java.lang.String.getBytes(String charsetName). This was not an issue with BEA JRockit 1.4.2 R24.

This has now been fixed.

CR275108

Previously, when using the lookfor parameter to the Ctrl-Break handler print_object_summary could crash BEA JRockit if certain kinds of references were found.

This has now been fixed. In addition, the output includes the kind of each reference.

CR275725

The implementation of BEA JRockit’s System.nanoTime() on Linux provided the time since BEA JRockit started. Now BEA JRockit uses gettimeofday instead, which makes it easier to use the time to compare different JVM instances.

CR276308

The verbose framework in BEA JRockit is now stricter and possible ambiguous shortcuts have been removed, for example, the option -Xverbose:compact no longer works, instead you need to use -Xverbose:compaction.

CR276311

BEA JRockit R26.3.0 could, under rare circumstances, crash when using -Xgc:gencon. All platforms were affected. This has now been fixed.

CR276460

BEA JRockit no longer fails on RHEL4 when using FileChannel.transferTo.

CR276987

In BEA JRockit R26 releases prior to R26.4, a breakpoint could be garbage collected if the garbage collection went off before the method was generated. This has now been fixed.

CR277702

The JraRecordingStarter.jar is no longer shipped with BEA JRockit. Use jrcmd instead to start a JRA recording.

CR278411

Previously, BEA JRockit incorrectly threw a BufferUnderflowException in java.nio.DirectByteBuffer.put() instead of BufferOverflowException when the buffer overflowed. This has now been fixed.

CR279712

Previously, the Ctrl-Break handler print_threads could result in a memory leak. This was due to handles that were not released during the printing of the thread status.

This problem has been noted on Linux and Solaris platforms only and it has now been fixed.

CR280443

Previously when you expanded types in the Type Graph in the BEA JRockit Memory Leak Tool, BEA JRockit hung and became unresponsive while consuming CPU resources. This issue has now been fixed.

Changes in the BEA JRockit R26.3 Release

Change Request ID

Description

CR257687

In BEA JRockit R26 releases prior to R26.3, BEA JRockit could crash due to a bug in the implementation of Class.getMethod(). The “this” reference was not treated properly by the garbage collector if threads were stopped in bad locations.

This has now been fixed.

CR258200

In BEA JRockit R26 releases prior to R26.3, BEA JRockit running could livelock due to a thread priority issue on Windows platforms.

This has now been fixed.

CR179421

BEA JRockit no longer misses to report some contended monitors to JVMPI.

CR189181

Explicit font support for Asianux, part of Red Flag Linux, has been added for BEA JRockit 5.0. The font support is based on the Red Hat Linux font support.

CR247026

In earlier BEA JRockit R26 versions, on Windows operating systems, BEA JRockit could sometimes expose a problem in the OS related to multimedia timers that caused the system time to be adjusted backwards.

This could cause the system time to jump back by about 1 minute. If this happened, you could turn off the use of multimedia timers with -Djrockit.periodictask.usemmtimers=false.

This problem has now been fixed.

CR248132

Explicit font support for Asianux, part of Red Flag Linux, has been added for BEA JRockit 1.4.2, keeping the support for Red Flag 4.1 font patch CR200703 for LANG=zh_CN.GB2312 locale. The font support is based on the Red Hat Linux font support.

CR251838

Previously a problem regarding the handling of TrueType fonts for certain font files caused a call to java.awt.Font.getXXX() methods that resulted in an IllegalArgumentException being thrown. This issue has now been fixed. (See, CR252610 for more information).

CR252610

The problem regarding the handling of TrueType fonts for certain font files has now been fixed.

CR254297

A race condition existed in BEA JRockit when the Memory Leak Server was stopped immediately after a client had connected, which caused sockets to be left in CLOSE_WAIT state. On Linux, this could eventually cause the BEA JRockit process to run out of file descriptors. This problem has now been fixed.

CR255271

The compaction for the deterministic garbage collector has been improved.
The following options have been added:

-XXinitialPointerVectorSize:<nn>
-XXmaxPooledPointerVectorSize:<nn>
-XXpointerMatrixLinearSeekDistance:<nn>

The option -XXcompactSetLimit now also works with -Xgcprio:deterministic.

For more information on how to use the options, see Reference Manual.

CR255959

A fix for SUN bug 5103041 has been added.

CR256867

The initialization of the initial (main) thread on Linux now respects the -Xss:<size> option, and commits an area corresponding to the largest of this and the current system stack rlimit (see ‘man rlimit’).

CR257039

The new option -XXdisableGCHeuristics disables the dynamic garbage collector selection heuristics when -Xgcprio is used. The JMAPI for changing garbage collectors in runtime can still be used.

Note:

If you disable the dynamic garbage collector selection heuristics, it will affect the behavior of the dynamic garbage collector and may lead to lower throughput or longer garbage collection pauses.

CR257799

JRockit now allows more than one JVMTI agent to get the can_tag_objects capability.

CR257905

(Linux only) When BEA JRockit was started from a process that blocks signal (such as Sun’s HotSpot JVM) it was not possible to send SIGQUIT to or use the jrcmd tool against BEA JRockit. This has now been fixed by unblocking signals that BEA JRockit listens to.

CR258248

You can now use the environment variable JROCKIT_DUMP_PATH to tell BEA JRockit to save crash dump information in a different location than the current working directory. The path specified must exist and be writable.

CR258395

BEA JRockit never called the JVMTI function Agent_OnUnload when the JVM shut down. This has now been fixed.

CR258894

When running BEA JRockit with gcprio:paustime or gcprio:deterministic, it is now possible to set the pausetime target using JMAPI or JLMEXT. See the javadocs for further information.

CR259231

Previously the JVMTI function GetObjectsWithTags was broken. This has now been fixed.

CR260241

BEA JRockit sometimes crashed while stepping into an ArrayIndexOfOutBounds-exception in the debugger on x86. This has now been fixed

CR260490

The new version of rtmon (librtm.so) is now compatible with Montecito systems, even if the kernel is not patched with the Montecito perfmon-2 patch. This means that there are no more failing on calls to RTMonRegisterThread() or RTMonStart(), which earlier caused BEA JRockit create a core dump.

CR262448

Multiple issues with -Xdebug in R24.5.0 have been fixed in this release.

CR262527

JRockit no longer fails to handle bytecode where the control flow enters an exception handler without a thrown exception.

CR262540

Previously when running HP OpenView Java Diagnostics Profiling Agent could cause crashes with BEA JRockit R26.0.0. This issue has now been fixed.

CR262571

Previously the sizeof parameter to the Ctrl-Break handler print_object_summary did not work as expected. This has been fixed.

CR262962

Hyperthreading detection has changed slightly, which makes BEA JRockit better at detecting wether Hyperthreading is available and turned on or off. This has also caused the BEA JRockit property jrockit.cpu.ia32.ht to default to the value “os” (OS detection) instead of “hw” (Hardware detection).

CR263376

RHEL 4.0 QU1 on Itanium contains a critical kernel bug that was corrected in QU2. Therefore, BEA require that you run BEA JRockit with RHEL 4.0 QU2 (or later) on Itanium systems.

For IA32 and x64, there are no known issues that require an update to QU2, and you can stay on QU1.

CR264064

The default stack size for Solaris on Sparc has doubled to 512 kB.

CR265225

The BEA JRockit JRE installer in Silent mode will now be correctly installed if the USER_INSTALL_DIR in the XML-file has been set.

See CR265227 for the previous known issue.

Changes in the BEA JRockit R26.2 Release

Change Request ID	Description
CR256719	The JVM experiences a slowdown with large number of threads doing reflective invocation of the same method concurrently.
CR239984	In earlier releases of the BEA JRockit JDK 1.4.2, it was necessary to specify `-Xmanagement:class=com.JRockit.management.rmp.RmpSocketListener` on the command line to start up the Management Server. This can now be done by simply specifying -`Xmanagement` or by setting the management server port with `jrockit.managementserver.port`.
CR249272	The property `jrockit.managementserver.usejmx` has been added for BEA JRockit JDK 1.5. Setting this property to false will make BEA JRockit use the RMP-protocol instead of the default management protocol (JMX) on a BEA JRockit JDK 1.5.
CR250218	When trying to print heap references, non-fatal JVMPI error messages were displayed. This has now been fixed.
CR250712	A race could cause BEA JRockit to crash during a JRA recording if a thread completed at the wrong moment. This race has been fixed.
CR252315	The compaction heuristics now ignore exceptional compactions when adjusting the compact ratio and pointerset limit.
CR252348	The option `-Xverbose:cpuinfo` is now available on IA64.
CR252567	The default stack size on X64 platforms has doubled from previous releases.
CR253588	The amount of free space is now calculated correctly when BEA JRockit calculates the maximum allowed nursery size during automatic nursery resizing.
CR253952	Several JVMPI problems have been fixed.
CR254354	For some garbage collectors, the minimum block size value, set by `-XXminBlockSize`, was also (incorrectly) used as thread-local area size. With this fix, increasing the `-XXminBlockSize` value will no longer affect the thread-local area size. If you have been using `-XXminBlockSize` to adjust the thread-local area size, you now must also set `-XXlargeObjectLimit` and `-XXtlaSize` to the same value as you set `-XXminBlockSize`, as described in the BEA JRockit Reference Manual.
CR257184, CR257379	The option `-Xpausetarget` didn’t always work when running `-Xgcprio:deterministic`. This has now been fixed.
CR257540	The JNI function `GetDirectBufferAddress` has now been changed to work with all direct `java.nio.Buffers`. Previously it only worked for direct `java.nio.ByteBuffers`.
CR257840	To make it easier to diagnose JRockit crashes, the option `-XXdumpfullstate` has been made default. This means that if BEA JRockit crashes a lot more information is saved to disk than was the case previously. To get the old behavior use `-XXdumpsize:normal`.
CR258002	Loading extra data from zip-file entries now work.
N/A	Java Web Start and the Browser Java Plugin was included in the previous 1.4.2 BEA JRockit version, i.e. BEA JRockit 1.4.2_08 R24.5.0. These features are dropped for BEA JRockit R26 on 1.4.2.

Changes in the BEA JRockit R26.0 Release

Change Request ID

Description

CR252874

In BEA JRockit 5.0 R25.2, there was an issue where an unexpected socket exception could occur, throwing the message java.net.SocketException: Socket Closed:Descriptor not a socket. This problem has been fixed.

CR211951

In previous versions of BEA JRockit, the JVM Process Load was capped to 100/number of CPUs on multi CPU Windows machines. This has now been fixed.

CR213687, CR213685

The non-supported option -XXprintStackOverflow has been added. This option produces a full stackdump when the StackOverFlowError is thrown.

CR218035, CR230226

In the previous release, BEA JRockit was known to hang or crash on 2.6 kernels on Itanium, due to a bug in the Linux 2.6.11 (and previous) kernel. The bug has now been fixed in kernel 2.6.12 by the Linux vendors.

Note:

To run this release of BEA JRockit, you need to use SLES 9 SP2 or RHEL4 U1 (or later).

CR219610

The default freelist cache size is 10% of the current heap size (with a minimum of 3 MB).

CR225145

Changes to java.vendor* system properties. The correct values are:

java.vendor = “BEA Systems, Inc.”
java.vendor.url = “http://www.bea.com/”
java.vendor.url.bug = “http://support.bea.com”

CR226460

The experimental code cache feature has been removed due to stability issues.

CR228592

Using the Memory Leak Tool could in some instances make JRockit freeze or crash. This has now been fixed.

CR228822

When running BEA JRockit on a single CPU machine, the code optimizer was in some cases too intrusive (true for BEA JRockit 5.0 R25.2.0). The problem was sometimes noticed at the first start of the WebLogic console. This problem has now been fixed.

In the previous release of BEA JRockit, this problem was worked around by setting the flag -Djrockit.codegen.optpriority=1; if you are using this flag, remove it when updating to this release.

CR229981

Improved behavior of internal locks that can lead to better performance during heavy loads.

CR230236

The -Xmanagement option resulted in an overhead even though the BEA JRockit Management Console was not connected. This has now been fixed.

CR232847

Improved floating point performance.

CR235100

The java.vm.version for the previous release was:
dra-45238-20050523-2021-win-ia32

The java.vm.version for this release is:
R26.0.0-188-52875-1.5.0_04-20051110-0917-win-ia32

The java.vm.info for the previous release was:
R25.2.0-28

The java.vm.info for this release is:
<empty>

CR235101

Previously, BEA JRockit calculated MemoryMXBean.getNonHeapMemoryUsage().used as the process virtual bytes minus the heap size. Now MemoryMXBean.getNonHeapMemoryUsage().used is calculated as the process rw memory minus the heap size.

CR235105

The heap occupancy trigger heuristics have been corrected.

CR235107, CR236922

When running JRockit with a concurrent garbage collector, the garbage collector starts before the heap is completely full to be able to finish the garbage collection before running out of heap memory.

tries to determine when a garbage collection needs to be triggered through heuristics, but in certain situations it might be beneficial to set this trigger by hand and to a fixed value. Use the following argument -XXgctrigger=<int>, where int is an integer that takes values between 0 and 100. The value specifies the amount of free heap, measured in percentage, that should be available for the argument to trigger.

CR235682

Previously selecting a generational, concurrent mark, concurrent sweep strategy resulted in a non generational, parallel mark, parallel sweep strategy being chosen. This has now been fixed.

CR236723

A warning appears at start-up if you are running with a “suspicious” thread system.

CR237093

The time for the reference update phase was measured incorrectly when running the parallel garbage collector. This made the statistics that the (compaction) heuristics are based on incorrect.

The pause target for compaction increased too fast when running static garbage collections. In this release, it can be increased with at most 50% for each garbage collection. The initial value has been set to 100 ms (this may be further tuned).

CR238220

CPU load and CPU description is now returned as CompositeData in JRockitConsoleMXBean.

CR239499

The Memory Leak Detector did not work properly when the management server was started by the Ctrl-Break handler (using ctrlhandler.act) as opposed to using the -Xmanagement startup option. This has now been fixed and the Memory Leak Detector works as expected, regardless of how the management server has been started.

CR239968

In previous versions of , the maximum stack trace depth value, in JRA recordings, was always 16 frames. In this version it is possible to set this value by adding the “tracedepth” option to -XXjra and the “jrarecording” ctrlbreak handler.

The default value is still 16 frames.

CR240355

In this release it is possible to change verbosity for the “memory,” “memdbg,” and “gcpause” subsystems using the ctrlbreak handler.

CR240359

The syntax for the “verbosity” ctrlbreak handler has changed. The previous argument “args” has been changed to “set.”

Run the ctrlbreak handler “help verbosity” for more details.

CR240510

The information from jrockit.verboserefs has been improved and now includes more details regarding garbage collection.
Support for verbose information in ctrlbreakhandler/jrcmd has been added.

CR241377

The default stack size on Solaris/Sparc is 256k.

CR241546

This release of BEA JRockit does not ship with Java Web Start or Java Plugin. Some earlier releases did and the installers and uninstallers of those versions do not behave properly when this release is installed. To avoid problems with the installation, do one of the following before installing :

Uninstall all earlier BEA JRockit JRE releases before installing this release. Java Web Start and Java Plugin will not be available after this process.
Install all earlier BEA JRockit JRE releases that are needed before installing this release. Java Web Start and Java Plugin will be available if included in any of the earlier releases.

Note:

Do not install or uninstall an earlier release of BEA JRockit JRE while this release is installed. Doing so may corrupt the state of Java Web Start and Java Plugin.

CR241638

The following compaction tuning flags have been added:

-XXinternalCompactRatio

Sets the number of heap parts to compact during internal compaction. Default is dynamic or 8 when running -Xgcprio:throughput.

-XXexternalCompactRatio

Sets the number of heap parts to compact during external compaction (aka “evacuation”). Default is dynamic or 8 when running -Xgcprio:throughput.

-XXheapParts

Sets the number of heap parts. Default is 128.

Furthermore, the system property jrockit.gc.usematrix has been turned into an -XX option.

-XXusePointerMatrix

Indicates that the pointer matrix should be used instead of the pointerset. The pointer matrix is default when running -Xgcprio:deterministic or -Xgcprio:pausetime.

CR241665

In the management API, the functions getMAC and getMTU are supported on Windows. On Unix systems these functions return an empty string or zero.

CR242307

To get fixes for potential security vulnerabilities, this release has upgraded zlib from zlib-1.2.1 to zlib-1.2.3.

CR242944

The command jrockit.oomdiagnostics.filename specifies where to write out of memory diagnostics (if this is enabled through jrockit.oomdiagnostics). If diagnostics are enabled and no file is specified, the output ends up where the -Xverbose information ends up (typically stderr).

CR244403, CR238634

Traversing superclasses of interfaces in find_method have been removed. These classes returned methods that were not declared in the interface or its super interfaces, for example, Object.*. The supermost class of an interface is always Object.

CR245707

JVMDI is not supported in the BEA JRockit R26.0 release (nor in the 25.0 or 1.4.2 builds); however, JDWP and JDI are supported. This means that remote debugging tools will still work as in previous releases.

CR245732

Previously, retrieving JMAPI stack traces could deadlock in certain cases for traces that included overridden hashCode methods that had been taking locks. This has now been fixed.

CR255294

Previously, when calling java.io.File.getCanonicalFile() on a path where java.io.FilePermission was not granted, the call did not fail as expected. This has now been fixed and the appropriate exception is thrown.

Known Issues

Issue

Description

BEA JRockit is crashing due to a signal handling conflict.

For Linux users only.

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

Workaround:

Set the environment variable LD_PRELOAD as follows:

export LD_PRELOAD=$JROCKIT_HOME/jre/lib/i386/libjsig.so

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:

http://java.sun.com/j2se/1.5.0/docs/guide/vm/signal-chaining.html

CR289856

Due to a bug in the Jikes 1.22 Java compiler, it cannot be used for compiling 1.4.2 Java code using the class libraries shipped with BEA JRockit R26.0.0 or newer releases.

The bug has been reported and is described at: http://sourceforge.net/tracker/index.php?func=detail&aid=1548770&group_id=128803&atid=712760

CR286338

In BEA JRockit 26.4, JRA Recordings always report that the heap usage is zero after a garbage collection with a single-spaced garbage collector. The


-Xverbose

:memory and -Xverbose:memdbg printouts report the correct value for the heap usage after garbage collection.

CR284602

The jrcmd tool might fail to find all BEA JRockit processes on a machine if there are any Java processes by other JVM vendors running on the same machine. Contact BEA JRockit Support for a patch that solves this problem.

CR283915

Long thread sleeps issued by Thread.sleep(...) and Object.wait(...) can end too early if the sleeps are longer than 0x3FFFFFFF milliseconds (approximately 12.4 days).

All platforms are affected.

CR283787

Upgrading from BEA WebLogic Platform 8.1 SP5 to 8.1 SP6 and running it on BEA JRockit R26 SP3 can result in a performance regression of up to 10%.

Workaround:

To avoid this regression, you can improve the performance of memory intensive applications by setting the command-line options -XXtlaSize:<default 2kB> and -XXlargeObjectLimit:<default 2kB>. See the “Special Note for WLP 8.1 SP6 Users Running on BEA BEA JRockit R26.3” for instructions on how to do this.

CR280443

When you expand types in the Type Graph in the BEA JRockit Memory Leak Tool, BEA JRockit can hang and become unresponsive while consuming CPU resources. This issue was introduced as a regression in BEA JRockit R26.2.

Note:

This has been fixed in R26.4.

CR279998

Objects that are allocated with reflection, for example, with java.lang.Class.newInstance(), do not show up in the allocation stacktraces in the Memory Leak Detector Tool.

CR279584

The synchronization code in java.util.Random.next() has been optimized for the case where there is no contention, i.e. the java.util.Random object is used by only one thread. A drawback of this optimization is worse performance if the object is used heavily in several concurrent threads. This typically happens if the convenience method java.lang.Math.random() is used.

To avoid this, create a new java.util.Random object instead of calling java.lang.Math.random().

CR278796

Null-pointer exception bypasses first catch block and is caught in the next.

A catch block immediately following “return x.y;” where the variable x points to null, will not catch the null-pointer exception. The exception will be caught in the next catch block.

public class Test {
   int y = 0;
   public static int foo() {
      try {
         Test x = null;
         return x.y;
      } catch (Exception e) {
         System.out.println(“It works!”);
      }
      return 0;
   }
   public static void main(String[] args) {
      try {
         foo();
      } catch(Exception ex) {
         System.out.println(“Failure!”);
      }
   }
}

CR276311

BEA JRockit R26.3.0 can, under rare circumstances, crash when using -Xgc:gencon. All platforms are affected.

Workaround:

Use another garbage collector or upgrade to BEA JRockit R26.4.0.

CR275524

On some Linux versions, the library functions exit() and _exit() do not always terminate the calling process. This causes BEA JRockit to hang during shut down on SLES 8.

Workaround:

Use a later SLES version.

CR274636

BEA JRockit 1.4.2 R26.2 and R26.3 throw a java.lang.NullPointerException when passing a null argument to java.lang.String.getBytes(String charsetName), while BEA JRockit 1.4.2 R24 did not. The behavior is unspecified but the change might cause problems when running TIBCO with XML messaging on BEA JRockit 1.4.2 R26.2 or R26.3.

Note:

This has been fixed in R26.4.

CR272699

Occasionally, when using a JVMTI Java debugger, breakpoints are not hit. This issue can arise with any R26 version of the product.

Workaround:

Start BEA JRockit with the option -XXnoCodeGC.

Note: -XXnoCodeGC is only intended for troubleshooting and is not recommended nor supported for production use.

CR271551

Buffers that have been allocated through ByteBuffer.allocateDirect() would not be released, even when discarded by the application, which causes C heap memory leaks.

Note:

This has been fixed in R26.4.

CR269115

BEA JRockit crashes when optimizing method. This issue can be identified by the following stack trace:

at renameVar+36()@...
at irCompactVars+240()@... 
at ssaConvertTo+2356()@...
...

This crash has only been noted on the Solaris on Sparc platform but might be a problem on other platforms as well.

Workaround:

Use optfile and remove the particular method that causes the crash.

CR268746

On older Linux distributions that run LinuxThreads instead of NPTL, BEA JRockit can sometimes hang when it is shutting down.

CR268439

Calling JVMTI functions from a non-attached thread will cause BEA JRockit to crash.

Note:

This has been fixed in R26.4.

CR268423

BEA JRockit releases previous to R26.3.0 do not contain the fix for the Australian Daylight Savings Time change for 2006. Please contact BEA Support for a patch

CR267987

Using java.nio.channels.SelectionKey.OP_CONNECT will make BEA JRockit block forever.

Note:

This has been fixed in BEA JRockit R26.4.

CR266871

BEA JRockit R26.0.0 on Linux IA32 can experience problems setting up memory for object allocation. It will manifest itself through this printout (and then exit BEA JRockit):

[JRockit] ERROR: Fatal error in JRockit during memory setup phase. Try to reduce the heap size using -Xmx:<size>m, i.e. “-Xmx:16m”. Could not create the Java virtual machine.

Workaround:

Try different -Xmx values to find a heap size that is setup correct.

Note:

This known issue is valid for R26.0.0. The problem is fixed in releases R26.1.0 and later.

CR266870

IA64 RedFlag 4.1 creates broken core files when programs crash. This makes it impossible for BEA JRockit engineers to resolve customer issues on RF41/IA64.

This has been reported at: http://www.redflag-linux.com/bugzillaAX/show_bug.cgi?id=1320

CR266667

Slow startup because of a hang in java.net.PlainSocketImpl.initProto(), which typically is called when creating the first Socket or ServerSocket.

In BEA JRockit 5.0 R26 the network stack is configured so that IPv6 is used in preference to IPv4 when it is present.

During initialization of the network stack, the network code connects a socket to its own loopback interface to set up some data structures. Blocking this connection (e.g. with a firewall) will cause the initialization code to wait for a socket timeout, after which the system falls back on using IPv4.

Workaround:

Either set -Djava.net.preferIPv4Stack=true, which forces Java to use IPv4 instead, or you disable IPv6 entirely in the system. The proper fix is to allow IPv6 traffic from localhost to localhost.

For more information, see the Sun documentation: http://java.sun.com/j2se/1.4.2/docs/guide/net/ipv6_guide/#ipv6-networking

CR265793

With JRockit 1.4.2 R26, java.lang.reflect.Array.set(Object array, int index, Object value) always throws NullPointerException when value is null without checking if array is of primitive type.

A patch addressing this issue is available through BEA support.

CR265227

The BEA JRockit in Silent mode will not be correctly installed if the USER_INSTALL_DIR in the XML-file has been set to anything other than the default installation path.

During the installation, the registry settings will not be set correctly, causing the .jar file association to fail. The files Java.exe and Javaw.exe will not be copied to %SystemRoot%\System32 either.

Note:

This problem has been fixed in R26.3.

CR264913, CR244553

A bug in the Linux operating system on x64 will cause BEA JRockit to crash if it is invoked from the pthread_once system call.

Workaround:

Install RHEL 4.0 QU3 or SUSE 9.0 SP3.

CR262540

An issue running HP OpenView Java Diagnostics Profiling Agent may cause crashes with BEA JRockit R26.0.0.

Note:

This issue has been fixed in R26.3.0.

CR262157

In rare cases BEA JRockit can print incorrect information about locks in the stack dump, given by the Ctrl-Break handler or by the Management Console/MAPI.

When a lock is taken by a method that has been optimized in a certain way (inlining), this lock can be printed as being taken, not only on the correct frame, but also as being taken on one or several nearby frames. This does not affect how BEA JRockit treats the lock when executing, only the stack dump itself.

CR256312

On Windows x64 and Itanium, when using the BEA JRockit JRE console mode installer to remove a previously installed BEA JRockit, the uninstall will be interrupted and the following message is displayed:

A fatal error has occurred. This application will terminate.

The uninstall information is now removed, but most of the files and registry settings are still left on the machine.

Workaround to completely uninstall the BEA JRockit JRE:

Run the installer in graphical mode and click Remove previous and reinstall when prompted; the BEA JRockit JRE is once again installed. To completely uninstall the BEA JRockit JRE (including its files and registry settings), use the graphical uninstall procedure.

CR252610

A problem regarding the handling of TrueType fonts for certain font files may cause a call to java.awt.Font.getXXX() methods that results in an IllegalArgumentException being thrown.

This problem has been reported to Sun as a problem found in Sun JDK 5.0 Update 4 in bug #6349101 ( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6349101). This problem can theoretically occur on all platforms but has been observed on RedFlag Linux Advanced Server 5.0 when the RPM package ttfonts-zh_TW-5.0-2AX.noarch.rpm is installed and the user is requesting a font with Chinese locale.

Workaround:

Uninstall the package ttfonts-zh_TW-5.0-2AX. This solves the problem but will at the same time remove those fonts from the system, which may cause other problems when trying to display Chinese text. If you try this, you should try to replace the use of the removed font with some other available font on the system.

Note:

The problem has been fixed in release R26.3.0, but since that release does not include an Itanium version, it is still a known issue for the R26.0.0 Itanium version.

CR251457

If ulimit -v is used on Linux to limit the virtual memory usage, BEA JRockit may crash if the limit is set too low. The x64 version of BEA JRockit requires a much larger setting because it reserves addresses for compiled code at startup. The BEA recommendation is to not use the ulimit -v setting at all.

CR251452

BEA JRockit needs enough virtual memory (address space) to be able to run properly. Note that a high value on allowed virtual memory does not imply high memory consumption. On Linux, the amount of available virtual memory can be changed, typically by the command ulimit -v <amount>.

The default is an unlimited address space, which is the recommended.Do not change this default, since it risks having BEA JRockit running out of address space, which in turn causes BEA JRockit to terminate immediately.

BEA JRockit requires at least the following amount of virtual memory to even start:

On IA64: 88 MB
On IA32: 61 MB
On x64: 1100 MB

Note:

If you start BEA JRockit with less virtual memory than twice the above values, you'll be given a warning. This is not recommended, and is likely to cause problems when running an actual Java application.

CR249667

Some applications may experience problems with the automatic nursery sizing heuristics when running in -Xgcprio:throughput (default) and -Xgcprio:pausetime mode. This causes too frequently triggered garbage collections.

Workaround:

Set the nursery size manually using -Xns:<size> or to select a static garbage collector.

The automatic heap resizing heuristics are not optimal for all applications. If your application has problems due to frequent garbage collections and the heap hasn’t been expanded to the maximum heap size, you can increase the initial heap size (-Xms:<size>) to improve the performance.

CR248565

When running BEA JRockit as an embedded service on Windows (for example, Jakarta Tomcat service wrapper), the directory <path-to-jdk>/jre/bin must be added to the PATH variable.

For more information, see:

http://edocs.bea.com/jrockit/geninfo/devapps/tshoot.html#998592

CR248551

When installing the 32-bit JRE on a Windows x64, the java.exe and javaw.exe files will not be copied to the system32 folder; they will be placed in the syswow64 folder instead.

This is expected behavior for 32-bit applications running on Windows x64.

CR247613

The “jrcmd” utility shipped in the Windows ia32 BEA JRockit package does not work on Windows x64. Instead, use the “jrcmd” utility shipped with the Windows x64 package of BEA JRockit.

CR246634

Thread priorities are supported on the Windows platforms only.

CR246224, CR260004

When doing a JRA recording on Windows XP x64, the JRA recording incorrectly displays that it has been done on Windows 2003 Server. The current implementation of BEA JRockit cannot separate between the two different operating system’s version information.

Note:

This known issue is valid for R26.0 and R26.1.

CR245914

Java applications (such as Eclipse) may hang on Linux distributions which use the “gamin” File Alteration Monitor implementation, for example RHEL4. This is due to a bug in gamin’s handling of signals.

Workaround:

Use “signal chaining” by loading the libjsig.so library. Do this by executing
> export LD_PRELOAD=$JDK_HOME/jre/lib/i386/libjsig.so
before starting BEA JRockit.

For more information on signal chaining see: http://java.sun.com/j2se/1.5.0/docs/guide/vm/signal-chaining.html

CR244773 CR250025

BEA JRockit’s nursery pool can be invalidated when the garbage collection strategy changes. According to the Java 2 Platform SE API documentation, a pool that has been invalidated may return null. Programmers must therefore assume that MemoryPoolMXBean#getUsage() and MemoryPoolMXBean#getPeakUsage() may return null at any time.

The MemoryMonitor demo and the VerboseGC demo can throw NullPointerExceptions, since these attributes are not checked for nulls.

CR243996

The VerboseGC demo, located at \demo\management\VerboseGC\VerboseGC.jar, can throw a NullPointerExcecption when used with a BEA JRockit that has a nursery.

According to the API specification for the Java 2 Platform Standard Edition 5.0 the method getUsage() of the MemoryPoolMxBean can return null if a memory pool is not valid, which can be the case when you run BEA JRockit with a nursery.

This validity check is missing in the demo and is the cause of the NullPointerException.

CR242655

In Windows, faulting code can be caught by Structured Exception Handling (SEH). The Microsoft C compiler allows a special construct, see below:

__try {
 // do something that can fail 
} __except (filterException()) {
 // handle the fault 
}

This sets up an SEH handler, which would get called if the code in the __try block fails (for example, a read/write to an illegal address).

However, on 64-bit Windows (IA64 and x64), BEA JRockit uses a new exception handling feature known as vectored exception handlers. The vectored exception handlers will be called before any SEH handler gets called. If the BEA JRockit vectored exception handler detects a fault in native code, it will make BEA JRockit produce a crash dump.

The effect of this is that you cannot use SEH on 64-bit Windows in native code that gets called by BEA JRockit. Either install a vectored exception handler yourself and add it first in the chain, or test the memory before trying to read/write to it with IsBadReadPtr().

CR232872

On RHEL3u6 and earlier, as well as RHEL4u2 and earlier, fork()ing new processes can sometimes fail. This can make in turn make Runtime.exec() fail. This has been fixed in RHEL3u7 and RHEL4u3.

The Redhat Issue Tracker case number for this is 77560. This isn’t available in Redhat’s public bugzilla.

CR210743

If you are running SLES 8.0, RFAS 4.1, RHEL 3.0 QU4 or older, you might run into serious IO problems.

Workaround (for RHEL):

Install version QU5 or later.

CR128962

IPv6 support for Windows is included as an unsupported feature in this release.