WebLogic JRockit 8.1 SDK is available either as a standalone application or as part of the BEA WebLogic Platform suite. For instructions on installing it as a standalone, please see Installing WebLogic JRockit 8.1 SDK. For instructions on installing it as part of WebLogic Platform, please refer to Installing WebLogic Platform.
For a detailed description of what is included in this service pack of BEA WebLogic JRockit 8.1 SDK, please refer to What's in the WebLogic JRockit 8.1 SDK?.
This section describes issues resolved in this service pack and other product-related notes. The issues described here were originally identified in WebLogic JRockit 8.1 SDK Service Pack 1 and earlier.
Class or method names that include multi-byte characters can cause WebLogic JRockit to hang or crash. Under certain conditions, when internal strings are converted to multi-byte strings, the JVM can cause a buffer overrun, which might result in it crashing or hanging up. If you encounter this situation, please contact support (email@example.com) to obtain a patch to work around it.
In some circumstances, WebLogic JRockit would crash when using JNI's
GetFieldId() and multiple threads called the function. It was discovered that the field cache was not thread safe. The JVM was modified so that read/writes are now guarded with spinlock.
GetFieldId() now works even when multiple threads are constantly calling it.
This version of WebLogic JRockit modifies the thread clean-up code to correct a problem with how the JVM's thread clean up resulted in their stack memory being left behind, thus, a memory leak. This was a race condition that meant a few stacks for every thousand threads cleaned up were not freed.
This problem occurred in Java programs that had a high thread turnover rate. The user would notice a gradual increase in process size over time, indicative of a memory leak. Java programs using Oracle JDBC drivers under certain conditions would also notice this problem, since this Oracle's driver may create threads for canceling transactions.
It was possible for an application with large heap to allocate enough threads to exceed the maximum, process size even when those threads have completed. WebLogic JRockit has been modified in this service pack to release terminated platform threads every 25 completions.
When used in a Linux 32-bit implementation, the
DatagramPacket.getAddress() was returning the first client address from which the packet has been received, whereas the Windows32-bit version would return the proper source address. WebLogic JRockit has been updated as of this version to correct this situation.
Some users experienced a problem when they started WebLogic JRockit an NT server and then stopped the service. Windows would generate an error message and then advise them that the Java service would be closed. Another message would then that indicate that the service could not be stopped. This situation has been corrected.
The version of WebLogic JRockit corrects a problem with the JVMs ability to control process size growth. In earlier versions of WebLogic JRockit, there were occasional problems controlling this growth, even if the Java heap was well within its limit and was almost constant during the run. This indicated a memory leak outside the heap, with the process size growing up to 2 GB before the process hung up or died.
In earlier versions of WebLogic JRockit, the JNI implementation was inconsistent with Sun's implementation. This inconsistency occasionally resulted in
nullString failures. The WebLogic JRockit implementation of JNI is now consistent with Sun's.
This service pack of WebLogic JRockit corrects a problem wherein Java applications having high thread turnover were prone to random crashes or hanging of the JVM. This problem occurred on all platforms, but was most frequently seen on 64-bit Linux machines. If a JRockit dump was produced after a crash or hangup, it would often be incomplete or show different problems each time it was generated.
If you are using 64-bit Linux, ensure that your glibc and kernel versions are up to date with the latest bug fixes from the RedHat Network:
If you are running the J2EE compliance test suite from Sun with WebLogic JRockit on WebLogic Server, we recommend that you set
-Xmx to the same size to prevent the system from dumping. If you do encounter a dump on startup, review your
-Xmx settings and reduce them, if necessary.
Some users have encountered an out-of-memory error when WebLogic JRockit tried to allocate a new byte array when running with jDriver. When the allocation fails
glibc threw a C++ exception which wasn't not caught, causing the program to dump core and terminate. At the same time, no jrockit.dump file is created. This problem has been corrected.
Occasionally, customers have seen some execute threads hang up in a
java.lang.Object.getMonitorIndexAndLock(Native Method), call while the CPU pegs to 100% utilization. This version of WebLogic JRockit has been enhanced to alleviate this problem by implementing the correct handling of native weak handles, which are more reachable than final and phantom handles.
The JDK cacerts file and the WebLogic Server cacerts file are keystore files that contain out-of-the-box trusted Certificate Authority certificates. These trusted CA certs are used in certificate chain verification when using SSL.
In this service pack, WebLogic Server checks each trusted CA certificate in the JDK and WebLogic Server cacerts files for the NotAfter date. If the trusted CA is due to expire (that is, exceed the NotAfter date) within 30 days, a warning message is output about this impending expiration. If a trusted CA has already expired, with one exception, a warning message is output declaring the trusted CAs as having exceeded the NotAfter date.
Two trusted CAs in the JDK cacerts keystore file are due to expire approximately at the release date of this service pack. Thus, you might see one or both of these warning messages output while booting WebLogic Server.
If you use either of these two trusted CAs in your server certificate chain, you should obtain a new trusted CA or certificate from your Certificate Authority of choice (Verisign, Certicom, and so on).
The current JDK cacerts file contains at least one certificate from Verisign that has expired (the Class 4 Certificate Authority, alias verisignclass4ca). No certificate expired message is output when this trusted CA is loaded.
For more information, see Sun Alert 57436 at http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F57436.
While the BEA download site only distributes WebLogic JRockit packages using the BEA installer, if you are subscribed to Red Hat Network, you can obtain WebLogic JRockit binaries in RPM format from the Red Hat Enterprise Linux AS channel. If you do obtain the WebLogic JRockit RPMs, you can relocate them from the default directory (
/opt/bea/jrockit81_141) to a directory you specify.
If you don't set the maximum heap size (
-Xmx), fragmentation might cause paging to occur, degrading system performance. This is because WebLogic JRockit grows the heap aggressively when fragmentation occurs, potentially out-stripping the physical memory available. Although WebLogic JRockit sets the default maximum heap size to 75% of physical memory in the system, it will grow the heap aggressively when the heap becomes fragmented. To avoid this situation, you should override the default and manually set -Xmx to no more than 75% of the available physical memory.
Starting WebLogic JRockit with the generational copy garbage collector (
-Xgc:gencopy) and a nursery explicitly set to more than 15% of initial heap size will cause the JVM to crash. To avoid this situation, either accept the default nursery size by not specifying
-Xns or set the nursery size to less than 15% of the
To ensure consistency of information displayed when
-Xverbose:memory is specified, the output for that option has been unified across all garbage collectors; that is, specifying
-Xverbose:memory will result in the same type of information displayed, regardless of the garbage collector used. For details, please refer to Displaying Logging Information in Starting and Configuring WebLogic JRockit.
This version of WebLogic JRockit (J2SE 1.4.1) now supports MS932 windows-31j encoding on jDriver. Previously, this support was not available because the windows-31j converter was not included in
lib/charsets.jar. This affected WebLogic JRockit's support for Japanese language implementations.
When running WebLogic JRockit on Linux some users were experiencing a "File size limit exceeded" exception and the application stopped, indicating that the JVM was not able to handle large (greater than 2 GB) files. This issue was reported in CR103219 and has been corrected. WebLogic JRockit now supports 64-bit files.
The root directory names for WebLogic JRockit SDK Linux installations are now the same, regardless of the Intel architecture used. Based on the installation method you use, the root directories are as listed in Table 1:
Although the JDK allows for zip file headers to contain more than 256 bytes of additional information, an exception was being thrown when these files became larger than that. This issue was reported in CR104622. In response, the
ZipFile() constructor was modified to support up to 64 KB of extra header information.
Red Hat Enterprise Linux AS / ES / WS 2.1users need to ensure that
glibc version i686 is installed, not
glibc version i386 version. Otherwise, you might encounter a segfault error upon startup. Additionally, do not add the folder
/lib/i386 to your
/lib is in
/lib/libpthread.so will be the linked runtime, instead of
The implementation of
java.lang.Runtime.freeMemory() has been corrected. Previously, it regarded the whole nursery as being free. Because of this, an application may incorrectly get the impression that WebLogic JRockit now uses more memory. This is not the case since previously a higher value than was actually free was returned.
If you start WebLogic JRockit with the
gencon garbage collector (either implicitly, as the default, or explicitly) and you specify explicit values for
-Xns, you will need to double the value specified for
-Xns to mimic the GA behavior.
CR101146 reports that WebLogic JRockit might throw an
IOException: Bad file descriptor if too many files are open. To work around this situation, increase the maximum number of files you can open to 2048 by setting
ulimit -n 2048. You can only increase this number if the maximum number of files you can open is equal to or greater than 2048. If maximum number of processes is lower than 2048, have your system administrator increase it to at least 2048.
If you are running a Linux version of WebLogic JRockit on an IA64 SMP machine and are using
Runtime.exec() extensively, you might encounter arbitrary crashes during processing. This issue, reported in CR104064, is caused by an O/S-level problem that has been resolved by a patch now available from RedHat at:
This section describes the issues were resolved in WebLogic JRockit 8.1 SDK GA and other important product-related information. The issues described here were originally identified in WebLogic JRockit 8.0 SDK and earlier.
If you are running a high-stress application with heavily contended locks on a multiprocessor system, you can attempt to improve performance by using the option
-XXenablefatspin. This option enables the ability to spin for a short time before going to sleep. While in most cases,
-XXenablefatspin improves performance slightly—particularly if the contended locks in your code are only held for a short period of time—be aware that, in some cases (perhaps up to 20%), it degrades performance. Future versions of WebLogic JRockit are expected to automatically adjust the spinning for different locks, eliminating the need for this option.
To be able to get CPU usage information in the JRockit Management Console from a JRockit instance running on Windows 2003 Server, the JRockit instance needs to be running as a user who has administrative rights on the computer in question.
Xis the cpu number) readable for any process. This is not a security problem, since almost all of this information is available through
/proc/cpuinfoanyway, and it is read only.
alias char-major-203 cpuidto your
Be sure to use only valid command line options when starting WebLogic JRockit JVM. If you use an invalid option, WebLogic JRockit will exit. Note that this behavior is different from that of previous versions of the VM, where it was ignored. For a list of valid command line options, please refer to Command Line Options by Name, in Tuning WebLogic JRockit JVM.
BEA will support WebLogic JRockit 8.1 SDK and provide bug fixes on only those operating system distributions that have been certified by BEA. While it may be possible to run WebLogic JRockit on other non-certified distributions, BEA makes no such guarantees. In addition, BEA will not be responsible for providing any bug fixes for non-certified distributions.