Release Notes

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

R26 Release Information

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

 

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-3 for an illustration of how the performance have been improved with the above improvements.

Figure 3-3 Performance improvements compared between BEA JRockit R26.3 and R26.4

Performance improvements compared between BEA JRockit R26.3 and R26.4

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

The following tuning options have been added in this release:

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

This has happened with BEA JRockit:

Changes in the BEA JRockit R26.4 Release

The following CRs have been corrected for 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:
CR258934
New arguments have been added to enable control of large pages ( -XXlargePages) on Solaris.
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

The following CRs have been corrected for the BEA JRockit R26.3 release.

Change Request ID
Description
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.
CR264064
The default stack size for Solaris on Sparc has doubled to 512 kB.
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.
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).
CR262571
Previously the sizeof parameter to the Ctrl-Break handler print_object_summary did not work as expected. This has been fixed.
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.
CR262527
JRockit no longer fails to handle bytecode where the control flow enters an exception handler without a thrown exception.
CR262448
Multiple issues with -Xdebug in R24.5.0 have been fixed in this release.
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.
CR260241
BEA JRockit sometimes crashed while stepping into an ArrayIndexOfOutBounds-exception in the debugger on x86. This has now been fixed
CR259231
Previously the JVMTI function GetObjectsWithTags was broken. This has now been fixed.
CR258894
When running BEA JRockit with gcprio:pausetime or gcprio:deterministic, it is now possible to set the pausetime target using JMAPI or JLMEXT. See the Javadocs for further information.
CR258395
BEA JRockit never called the JVMTI function Agent_OnUnload when the JVM shut down. This has now been fixed.
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.
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.
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.
CR257799
JRockit now allows more than one JVMTI agent to get the can_tag_objects capability.
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.
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.
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).
CR255959
A fix for Sun bug 5103041 has been added.
CR255271
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.
CR252610
The problem regarding the handling of TrueType fonts for certain font files has now been fixed.
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).
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.
CR247393
Linux and Solaris man pages have been removed.
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.
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.
CR179421
BEA JRockit no longer misses to report some contended monitors to JVMPI.

Changes in the BEA JRockit R26.2 Release

The following CRs have been corrected for 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 Java Plug-in were 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

The following CRs have been corrected for the BEA JRockit R26.0 release.

Change Request ID
Description
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, 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 Plug-in. 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:
  1. Uninstall all earlier BEA JRockit JRE releases before installing this release. Java Web Start and Java Plug-in will not be available after this process.
  2. Install all earlier BEA JRockit JRE releases that are needed before installing this release. Java Web Start and Java Plug-in 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 Plug-in.

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

The following issues are known in BEA JRockit R26:

Issue
Description
Untracked
For Linux users only.
BEA JRockit is crashing due to a signal handling conflict.
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
CR361457
Connecting the Memory Leak Detector to a running JRockit JVM (version R26.3 through R27.5) built for Linux IA-32 might cause the JVM to crash if the JVM process uses more than about 1020 file descriptors at the time. This might only happen if the file descriptor limit has been set higher than 1024 (typically by using the ulimit command).
Workaround:
Currently you can start the Memory Leak Detector Server at JVM startup, when few file descriptors are in use. To do this, add -Djrockit.memleak.port=12345 early in the JVM command line.
Now, using JRockit Mission Control, create a custom connection in the JRockit Browser with a Custom JMX service URL of service:jmx:mlp://localhost:12345. (Replace localhost and the port 12345 as needed). Using this connection, you can connect the Memory Leak Detector in JRockit Mission Control to this JVM once (without restarting the JVM).
Note that using many file descriptors might be an indication of a resource leak in the Java application. Make sure to always close opened files and sockets. You should not rely on the Garbage Collection and the object finalization to free a non-Java resource such as a file descriptor. See Too Many Open Files at:
https://support.bea.com/application_content/product_portlets/support_patterns/wls/TooManyOpenFilesPattern.html
for more information.
CR311515
The new explicit font support for Asianux, part of Red Flag Linux, available since BEA JRockit R26.3.0 depends on the existence and contents of the file /etc/asianux-release to correctly identify a Asianux compatible Linux distribution. If this file is not present the JRockit JDK or JRE will revert to look for /etc/redhat-release and instead identify a Red Hat Linux compatible distribution with Red Hat compatible font support.
The font support for Asianux is based on the font support for Red Hat Linux, with an additional patch for Chinese LANG=zh_CN.GB2312 locale for Red Flag Advanced Server 4.1 (and higher) in JRockit 1.4.2. Thus, if you are using Chinese zh_CN locale with JRockit 1.4.2 R26.3.0 and later on Red Flag Advanced Server 4.1 (and higher), that does not contain the file /etc/asianux-release, then BEA JRockit will load the Red Hat-specific font.properties.zh_CN.Redhat file instead of the expected Asianux-specific font.properties.zh_CN.Asianux file. This might cause the JVM to fail and result in unexpected behavior when it tries to load specific fonts with incorrect paths.
On Red Flag Advanced Server 4.1 and Red Flag Advanced Server 4.1 (SP1) the file /etc/asianux-release file might not be installed by default and if that is the case you can apply either one of the following workarounds.
- Install the optional RPM package asianux-release, if available. This is the preferred solution. On Red Flag Advanced Server 4.1 (SP1) the optional package asianux-release may conflict with the possibly already installed optional package redflag-release, you may choose to either uninstall the redflag-release package before installing the asianux-release package, or to force install the asianux-release package in parallel with the redflag-release package.
- Manually replace the contents of <jdk>/jre/lib/font.properties.zh_CN.Redhat with the contents of <jdk>/jre/lib/font.properties.zh_CN.Asianux.
CR307903
If a thread is interrupted for garbage collection while it is in the process of copying an array, then the garbage collection may result in very long pauses. If you get occasional long pause times, this may be the problem. Note that this issue has been fixed in BEA JRockit R27.2.
CR307902
For Linux users only.
If you explicitly request to use the Motif AWT instead of the default X11 AWT on Linux/IA64 and run a Linux version with a GLIBC version older than glibc-2.3.4, this operation might fail with an UnsatisfiedLinkError since the file <jre>/lib/ia64/motif21/libmawt.so requires linkage to GLIBC >= 2.3.4.
See the see the Supported Configurations document for supported Linux versions.
CR300097
There is a known bug in RedFlag 5.0 with the wait() call that might cause undetermined behavior for RedFlag customers using this OS version
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>.
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.
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.
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 Red Hat Issue Tracker case number for this is 77560. This isn’t available in Red Hat’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.


  Back to Top       Previous  Next