Oracle JRockit R27.7.1 supports these versions of the Jave JDK:
Java 6 SE Update 26
J2SE 5.0 Update 30
J2SE 1.4.2_32
New Features and Enhancements in the Oracle JRockit JVM R27.7
The Oracle JRockit JVM R27.7 is a maintenance release and contains no new features.
Java version updates in this release: J2SE 1.4.2_32, J2SE 5.0 Update 30, Java SE 6 Update 26.
New Features and Enhancements in the Oracle JRockit JVM R27.6
The Oracle JRockit JVM R27.6 is a maintenance release and contains no new features. For information on resolved issues and any changes to existing functionality in this version, please see Changes in the Oracle JRockit JVM R27.7.
JRockit Mission Control Client 3.1.0 contains a large number of new features that will provide more information more seamlessly and improve the overall user experience. For descriptions of these features, please refer to
New Features and Enhancements in this Release at:
Java version updates: 1.4.2_16, J2SE 5.0 update 14, Java SE 6 update 3.
Eclipse Integration of JRockit Mission Control
JRockit Mission Control is now available as an Eclipse plug-in edition. The plug-in version of Mission Control provides seamless integration of BEA JRockit’s application profiling and monitoring toolset with the Eclipse development platform. By integrating Mission Control with Eclipse, you will have easy access to the powerful toolset that comprises Mission Control.
When Mission Control is run within the Eclipse IDE, you have access to IDE features that aren’t otherwise available in the toolset when it is run as a standalone Rich Client Platform (RCP) application. The most significant of these features is the ability to see specific code in the running application by opening it directly from Mission Control, a function called Jump-to-Source.
The other benefit of integrating Mission Control with the Eclipse IDE is that it allows you to profile and monitor an application during its development phase just as you would during its production phase. This allows you to spot potential runtime problems before you actually deploy your application to production; for example, you might, while monitoring an application during its development notice a memory leak. By catching the memory leak during development, you can correct it before you migrate your application to a production environment.
The following updates have been made to JRockit Mission Control. These updates apply to both the RCP version and the Eclipse plug-in version.
The JRockit Runtime Analyzer now shows the number of bytes of objects allocated by each Java thread.
Three sample files that demonstrate the features of the Latency Analysis Tool have been added. The files are located at JROCKIT_HOME/missioncontrol/samples/jrarecordings/. The files are:
pricing_server_logging_on.jra
pricing_server_logging_off.jra
java2d_demo.jra (This file is a recording of the demo located at JROCKIT_HOME/demo/jfc/Java2D. The Java2D demo folder contains the source, allowing this recording to demonstrate Jump-to-Source (Jump-to-Source is only available when you are running Mission Control within Eclipse, as described in Eclipse Integration of JRockit Mission Control).
Small adjacent Latency Analysis Tool (LAT) events of the same type are now clearly marked to make them easier to distinguish.
Configurable velocimeters (Figure 2-1) have been added to the Console
Figure 2-1 Configurable Velocimeter
You can see the exact numerical value for a point in a graph in a tooltip by hovering your mouse pointer at the point.
Note:
This feature is only available when the graph is frozen.
Figure 2-2 Displaying the Value for a Point on a Graph
The time ranges of graphs shown on the same page can be synchronized.
You can filter attributes by name in the attribute browser when you select attributes to add to a graph or similar.
Thread transitions—a latency event in one thread that is associated with another thread—are now displayed as small black arrows on the Latency Graph, as shown in Figure 2-3. By hovering your pointer over a transition arrow, a tooltip will appear, describing the transition.
This version of Oracle JRockit includes updates to some of the command-line options used at startup.
-Xverbose
A new verbose logging module,-Xverbose:refobj has been added. At info level this module provides low overhead information on java.lang.ref.Reference objects at each garbage collection. At the debug level, this module prints out information equivalent to the info level printouts from the old -Xverbose:referents module.
-XpauseTarget
The-XpauseTargetvalue can now be set as low as 1 ms. The real minimum pause target still depends on the application size and behavior and the hardware.
-XlargePages
By default the JVM will continue running without large pages if large pages cannot be acquired when
-XlargePages is enabled. This option now can use the parameter exitOnFailure=false to override this behavior and force the JVM to exit if enough large pages can't be acquired; for example:
-XlargePages:exitOnFailure=false
New Features and Enhancements in the Oracle JRockit JVM R27.4
Oracle JRockit R27.4 is a maintenance release and contains no new features. New features available in the associated version of JRockit Mission Control (JRockit Mission Control 3.0.1) are described in that product’s
Release Notes at:
BEA JRockit R27.3 has been updated to use J2SE 1.4.2_14, J2SE 5.0 Update 11, and Java SE 6 Update 1.
BEA JRockit Mission Control 3.0
An updated version of BEA JRockit Mission Control is bundled with BEA JRockit R27.3. For a full description on what the release contains, see the BEA JRockit Mission Control Release Notes.
GUI Localizaton
The Oracle JRockit Mission Control GUI is now also available in Japanese and simplified Chinese.
Localized Documentation
Later in the summer of 2007, documentation also will be available in Japanese and simplified Chinese.
Figure 2-4 demonstrates the release-to-release improvements to out of the box performance. The large increase between R27.1 and R27.2 coincides with the introduction of JRockit for Java SE 6. R27.3 contains further enhancements.
Figure 2-4 SPECjbb2005 Out of the box improvements from R26.0 to R27.3
Improved Nursery
A new nursery implementation was introduced in R27.2, providing significant enhancements to application throughput as well as garbage collection pause times. This implementation has been refined in R27.3, leading to further improvements in performance (see Figure 2-5).
Figure 2-5 SIP benchmark results—further improvements from R27.2
Debugging Performance
Single-stepping in debug mode on single-CPU machines is now significantly faster than in previous JRockit versions.
New Features and Enhancements in the Oracle JRockit JVM R27.2
This section describes new features and enhancements released in this version of BEA JRockit It includes information on the following subjects:
BEA JRockit for Java SE 6 is current available on x86 and 64-bit Xeon/AMD64 platforms.
Java 1.4.2 and 5.0 Updates
BEA JRockit R27.2 has been updated to use J2SE 1.4.2_13 and J2SE 5.0 Update 10.
New Platform Support
BEA JRockit is now supported on Windows Vista and Red Hat Enterprise Linux 5.0.
Attach API Support
Oracle JRockit now supports Sun Microsystem’s Attach API, a Java extension that provides a way to attach tools written in Java to BEA JRockit JVM. For details, please refer to
Attach API Support at:
The System.nanoTime() method has been improved to always use the best time resolution available on each platform. For more information about the System.nanoTime() method, see Timing with nanoTime() and
CurrentTimeMillis() in the BEA JRockit Diagnostics Guide.
Performance Improvements
This version of JRockit includes numerous performance enhancements, including an improved nursery implementation, software prefetching, and garbage collection heuristics. These enhancements will improve performance by an average of 10% over a broad range of applications, with the largest benefits expected for memory intensive applications and out-of-the-box configurations.
The following performance improvements can be noticed for this release:
The R27.2 release includes a new nursery implementation, which yields better application throughput and shorter nursery garbage collection pause times.
Improved Software Prefetching
Software prefetching, previously enabled with the options – XXallocPrefetch and -XXallocRedoPrefetch, is now enabled by default. This can improve performance by up to 40%.
Note:
To fully benefit from this feature on Intel Xeon servers, it is recommended that you disable hardware prefetching in the computer’s BIOS.
Improved Garbage Collection Heuristics
Nursery sizing heuristics have been improved for the default garbage collection algorithm (
-Xgcprio:throughput), leading to better application throughput.
The default configuration of the – XXgcThreads option has been improved, resulting in better out-of-the-box behavior for latency sensitive applications. In most cases, there is no longer a need to tune this option manually.
Examples of Performance Improvements
To demonstrate the performance improvements in JRockit R27.2, see the following benchmark results:
The results on the SPECjbb2005 benchmark clearly shows the performance improvements that an upgrade from R27.1 to R27.2 can bring.
In Figure 2-6, a benchmark comparison between the BEA JRockit R27.1 and R27.2 releases is shown, where the JVMs have been tuned for optimal performance with various start-up options.
Figure 2-6 SPECjbb2005 performance improvements using tuned JRockits
As you can see, R27.2 shows a performance increase of more than 30% compared with the R27.1 release.
The most impressive SPECjbb2005 benchmark result was generated when R27.1 and R27.2 were compared completely out of the box, without any performance tuning. Figure 2-7 demonstrates the improvements in performance that the new and improved out-of-the-box behavior provides. The out of the box performance improvement is almost 70%.
Figure 2-7 Out of the box (OOTB) performance improvements
WLSS Benchmark
This is a benchmark that demonstrates the performance benefits of the new nursery implementations. The application is characterized by a large number of short lived sessions, leading to high memory allocation and short lived objects. Performance is measured in calls set up per second, under the boundary condition that 95% of the call setups should be done within 50 milliseconds. These requirements imply that the application benefits from an efficient nursery. Figure 2-8 visualizes the improvement.
Figure 2-8 SIP benchmark results
Supportability Features
There is a new verbose module for referents. Use the start-up option
-Xverbose:referents or the jrcmd parameter verbosity set=referents=info to make the JRockit JVM print verbose information on reference objects.
JRA Improvements
In BEA JRockit Runtime Analyzer, you can now see how long JRockit had been running before the start of the JRA recording. In addition, a list of all processes running on the host is included in JRA recordings.
New Command-line Options
The following command-line options have been added to Oracle JRockit R27.2. For a description of any option, please refer to the Oracle JRockit JVM
Reference Manual.
The command-line options listed in Table 2-1 have been updated. For full descriptions on all command-line options, please refer to the Oracle JRockit
Reference Manual.
A completely new version of BEA JRockit Mission Control is bundled with JRockit R27.1. This version contains a large set of usability enhancements, online documentation, and even more detailed diagnostics data, see the BEA JRockit Mission Control Release Notes.
Improved Monitoring and Diagnostics
The verbose logging framework in JRockit has been completely reworked. It now provides fine granular control over a large number of JVM subsystems, such as memory and threads, and it allows you to specify the amount of log data from each subsystem, log destination, and a variety of decorations, such as configurable time stamps.
Verbose logging can be controlled in several different ways:
The Java management (JMX) implementation in BEA JRockit 5.0 R27.1 has been changed to require security to be enabled by default. It also requires you to specify the IP port for the management server explicitly. To revert to the old behavior, use: -Xmanagement:ssl=false,authenticate=false,port=7091. See -Xmanagement in the Reference Manual for details. This change does not affect JRockit 1.4.2.
Improved Supportability
This version of JRockit also includes several supportability enhancements, including improved crash files, JVM self-checks, and other features. While these features are not intended for end-users, they will facilitate communication with BEA Support and speed up problem resolution.
JVMTI, which enables you to connect on-demand from any JVMTI client supporting this functionality.
Improved Documentation
A completely new Diagnostics Guide has been added to the JRockit product documentation set. This guide will help you troubleshoot JRockit and your applications.
IPv6 Support
IPv6 is now available on all platforms supported by JRockit.
Expanded Support for Solaris
JRockit is now available for both J2SE 1.4.2 and 5.0 on Solaris/SPARC.
Performance Improvements
This version of JRockit includes numerous performance enhancements. One example is that performance has been improved for J2EE applications using a large number of JSP pages and servlets. These enhancements are expected to improve performance on many WLS applications by 10-15%, see Figure 2-9.
Figure 2-9 WLS Benchmark—JRockit R26.4 vs. JRockit R27.1
The release also includes a number of generic enhancements, as demonstrated by improved scores on the SPECjbb2005 benchmark. See Figure 2-10 for a comparison between the Oracle JRockit R26.4 and Oracle JRockit R27.1 releases.
Figure 2-10 SPECjbb2005 performance improvements
Out of the box performance has also been improved due to:
Improved default configuration for memory allocation, see -XXtlaSize in the Reference Manual.
Compressed references is now available on all 64-bit platforms (x86-64, Itanium, and SPARC) and is enabled by default.
Plus other enhancements, see Figure 2-11 for a comparison between the Oracle JRockit R26.4 and Oracle JRockit R27.1 releases.
Figure 2-11 Out of the box performance
New Command-line Options
The following start-up commands have been added with Oracle JRockit R27. For a description of any new option, please refer to the specific option in the Oracle JRockit
Reference Manual (by clicking on the option name in the following list).
The rules for how command-line parameters are parsed have been updated to avoid user confusion. Incompatible command-line combinations now cause Oracle JRockit to print out an error message and terminate. Please refer to the specific option in the Oracle JRockit
Reference Manual (by clicking on the option name in Table 2-2) for a description of the new behavior.
Table 2-3 lists changes in Oracle JRockit JVM R27.6.9.
Table 2-3 Changes in the Oracle JRockit JVM R27.6.9
Issue
Description
10110908
The calculated LoadedClassCount MBean exposed negative values (TotalLoadedClassCount - UnloadedClassCount = LoadedClassCount). This problem was triggered when too many classes were failing class file resolution. This has been fixed.
Changes in the Oracle JRockit JVM R27.6.8
Oracle JRockit JVM R27.6.8 contains no notable changes from Oracle JRockit JVM R27.6.7.
Changes in the Oracle JRockit JVM R27.6.7
Table 2-4 lists changes in Oracle JRockit JVM R27.6.7.
Table 2-4 Changes in the Oracle JRockit JVM R27.6.7
Issue
Description
9486409
Occasionally, calling java.lang.util.zip.Deflater.deflateBytes() after calling java.lang.util.zip.Deflater.end() would cause the Oracle JRockit JVM to crash. This has been fixed; now, instead of crashing, a proper NullPointerException is thrown.
9227236
When a user would initialize a java.util.zip.ZipEntry instance that had been created for an uncompressed entry (method STORED), the uncompressed and compressed fields would not be initialized with the same value, sometimes causing a java.util.zip.ZipException. This has been fixed.
Changes in the Oracle JRockit JVM R27.6.6
Table 2-5 lists changes in Oracle JRockit JVM R27.6.6.
Table 2-5 Changes in the Oracle JRockit JVM R27.6.6
Issue
Description
9108982
On rare occasions, a race condition was occurring when several threads were trying to initialize the same class. This has now been fixed.
9104797
With -XX:+UseCfsAdaptedYield, customers using the CFS thread scheduler on Linux might see pause time improvements in the garbage collector.
9059394
Due to an OS bug, Oracle JRockit running on Windows 2008 (and Vista) might have crashed during start-up when Terminal Services were installed. This has been fixed
9050465
With SPARC implementations of Oracle JRockit that had numerous live variables and unchecked array index out of bounds exceptions, the contents in some registers could have been corrupted. This has now been fixed.
9000555
The Oracle JRockit optimizing compiler was, in rare cases, generating code that erroneously removed stores to copies of non-integer typed arrays, which was leading to incorrect computational results. This has been fixed.
8929771
In rare circumstances, SPARC Solaris implementations of Oracle JRockit was crashing when applications were trying to load a lot of code. This has been fixed
8841076
When using bitwise operations and casting, sign extension could, under some circumstances, be lost, resulting in incorrect values. This has now been fixed.
Changes in the Oracle JRockit JVM R27.6.5
Table 2-6 lists changes in Oracle JRockit JVM R27.6.5.
Table 2-6 Changes in the Oracle JRockit JVM R27.6.5
Issue
Description
9032858
Oracle JRockit R27.6.5 contains back ports of all Sun security fixes from the following Sun Java versions:
Recent updates to the Sun JDK versions 1.6.0_14 and 1.5.0_19 created an incompatibility issue with the SSL implementation on Oracle JRockit R27.6.4 (1.6.0_14 and 1.5.0_19) and certain versions of Oracle WebLogic Server. Patches are now available to resolve this issue.
The reported heap usage after a garbage collection did not include data stored in one of Oracle JRockit's caches. This has been fixed.
8781977
Core file resource limits are now printed out correctly in the Oracle JRockit textual dump file.
8770723
Under very rare circumstances, some optimized methods would perform faulty arithmetic. This has been fixed.
8740199
When optimizing System.arraycopy() the Oracle JRockit compiler was, in some cases, failing to recognize explicit types checks on the destination array, which could have caused semantic errors in the optimized code. This has been fixed.
8649273
The Oracle JRockit textual dump file now includes the value of LD_PRELOAD on Linux and LD_PRELOAD, LD_PRELOAD_32, LD_PRELOAD_64 on Solaris.
8567923
Under some circumstances, when using the genconcon collector , Oracle JRockit would corrupt the free list. This has been fixed.
8258685
Sometimes, JVMFactory.getJVM().getMachine().getPhysicalMemory().getUsedMemory() would return 0. This has now been fixed.
8235000
Oracle JRockit JDK 5.0 and 1.4.2 could crash in method Java_sun_dc_pr_PathFiller_writeAlpha8 (Sun bug #6464341). This has been fixed in Oracle JRockit 5.0 R27.6.5 and Oracle JRockit 1.4.2 R27.6.5.
8173162
Oracle JRockit JDK 5.0 and 1.4.2 was hanging when reading JPEG images with embedded ICC profiles (Sun bug #4528643, #6295525). This issue has been fixed in Oracle JRockit 5.0 R27.6.5 and Oracle JRockit 1.4.2 R27.6.5.
7690841
Threads waiting on a java/nio/channels/Selector.select() call on Windows plaforms were not being released if interrupted. This has been fixed.
Changes in the Oracle JRockit JVM R27.6.4
Table 2-7 lists changes in Oracle JRockit JVM R27.6.4.
Table 2-7 Changes in the Oracle JRockit JVM R27.6.4
Issue
Description
8583868
In rare circumstances involving malformed zip-files, Oracle JRockit could crash. This has been fixed.
8567164
Oracle JRockit was leaking memory when notification was used on MemoryMXBeans. This has been fixed.
8551200
Under some circumstances BigDecimal.valueOf() would return null instead of zero. This has been fixed.
8548547
During certain optimizations, the thread would run out of stack memory. This has been fixed.
8545562
-Xverbose:stackoverflow now works correctly when printing full stack traces upon Stack Overflow Errors.
8479419
Oracle JRockit was crashing on Windows platforms when it was recursively taking spinlocks exactly 16 times on bytecode compiled by Oracle Java Compiler (OCJ). This has been fixed.
8405290
Previously, when running bin/jrcmd -f <file>, only the first line of the file was run. This has been fixed.
8343063
On the Sparc platform, the contents of a register could be overwritten by an exception handler if the method contained many local variables. This has been fixed.
8194509
The Oracle JRockit optimizing compiler was occasionally generating erroneous code resulting in Null Pointer Exceptions being thrown from org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.getMethods() of the Eclipse IDE. This has been fixed.
8178388
Oracle JRockit can now handle zip- and jar-archives larger than 65535 files.
Changes in the Oracle JRockit JVM R27.6.3
Table 2-8 lists changes in Oracle JRockit JVM R27.6.3.
Table 2-8 Changes in the Oracle JRockit JDK R27.6.3
Issue ID
Description
8282822
On 64-bit Windows Vista/2008, the 64-bit JRockit installer executable is now properly manifested to request the administrator execution level.
This issue was originally tracked in CR363487.
8187650
Starting with Oracle JRockit Mission Control 3.1.0 and Oracle JRockit Real Time 3.1.0, each product installation directory is also an Oracle home, allowing additional product registration with the Oracle Central Inventory. The Central Inventory contains information about all installed Oracle products on the same host and can be managed by running the Oracle Universal Installer.
8186383
A condition in which a JRockit JDK installation running applications on compositing window managers under Linux might fail and generate the following error message:
has been fixed in Oracle JRockit 5.0 R27.6.3 and Oracle JRockit 6 R27.6.3.
This issue was originally tracked by CR349882.
8179196
Starting with Oracle JRockit Mission Control 3.1.0 and Oracle JRockit Real Time 3.1.0, the demo and sample programs and the source code of the Java platform are no longer installed by default. They have been separated into optional components that you explicitly select in order to install.
Changes in the Oracle JRockit JVM R27.6.2
Table 2-9 lists changes in Oracle JRockit JVM R27.6.2
Table 2-9 Changes in the Oracle JRockit JDK R27.6.2
Issue ID
Description
7574848
Certain XSLT/XSL transformations could on occasion throw ClassCastExceptions. This has now been fixed.
Changes in the Oracle JRockit JVM R27.6.1
Table 2-10 lists changes in Oracle JRockit JVM R27.6.1
Table 2-10 Changes in the Oracle JRockit JDK R27.6.1
Issue ID
Description
8187000
The JRA could cause a JVM crash at the end of a recording, while zipping the file, if the JVM process was low on memory. This has been fixed and JRA will now output an error message instead.
8184406
3D rendering with extensive use of xmm registers could occasionally cause the JVM to crash. This has now been fixed.
8183855
External compaction missed a part of the heap when the area to compact shrunk. This is now fixed.
8181106
Oracle JRockit versions R27.5 and R27.6 can crash when executing optimized code for the java/lang/StringBuffer.lastIndexOf() method on 64-bit platforms. The compiler no longer generates broken code for this method.
8180938
Oracle JRockit could, on occasion, crash while optimizing methods, resulting in stack traces pointing to removePhi. This has now been fixed.
8178677
Occasionally, reading the Manifest from an rt.jar distribution using JarInputStream returns NULL for certain rt.jar distributions. This has been fixed.
8178674
Oracle JRockit was crashing due to corruption of internal data structures while garbage collecting heaps with pinned objects allocated close to the nursery keep area. This has been fixed.
8176433
The Oracle JRockit optimizing compiler could generate faulty x86 code, leading to erroneous results for Java code operating on floating-point return values of method calls. This has been fixed.
8175793 8174814 8124284
The Oracle JRockit optimizing compiler can consume large amounts of memory when compiling large methods with complex control-flow (such as large JSPs). On 32-bit platforms this can lead to OutOfMemory errors. This has been fixed.
8097260
JRockit Mission Control was unable to open LAT recordings that contained threads that didn’t have names. This has been fixed.
Changes in the Oracle JRockit JVM R27.6.0
Table 2-11 lists changes in Oracle JRockit JVM R27.6.0.
Table 2-11 Changes in the Oracle JRockit JDK R27.6.0
Issue ID
Description
CR371396
When a full compaction was issued, all references in the heap wanted to be stored in the compact set. If a limit was set on the compact set, it would likely skip the compaction due to too many pointers. This has been fixed.
CR366936
In previous releases of the JRockit JVM, unloading class hierarchies that had many unloaded types sharing a common superclass or implementing the same interface could cause very long pause times. This has been improved in R27.6 .
CR366265
Technical license checks have been removed.
CR366238
The JRockit JVM running with WebLogic Event Server on Sparc systems was crashing in cgStoreMetaInfo, indicating a known issue in delay slot scheduling. The delay slot scheduling bug has been fixed and the system is no longer crashing.
CR364912
In previous versions of the JRockit JVM, a thread suspended in a debugger in a call chain for a static initializes could cause a crash while reading local variable information on the receiving type for the method initializing the class. This has been fixed.
CR361911
Calls to java.lang.management.CompilationMXBean.getTotalCompilationTime() previously returned 0. This has been fixed.
CR361457
Connecting the Memory Leak Detector to a running JRockit JVM built for Linux IA32 could cause the JVM to crash if the JVM process used more than about 1020 file descriptors at that time. This has now been fixed.
CR360910
The JRockit JVM did not properly handle error codes returned from Agent_OnAttach. If an error was returned, the JVM was aborted. This has been fixed.
CR359309
The ACLs (Access Control Lists) on the per-user <TEMP>\hsperfdata_<user> directory are set up such that users with administrator privileges have the rights to delete the directory. This only affects Windows versions of the JRockit JVM. For more information, please see: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5073453.
CR358260
When a large number of classes (~10,000) implementing the same interface were unloaded at the same time, unregistering them from the Interface could take a long time. This has been fixed
CR357526
The maximum number of active Object monitors has been increased to 4,194,304.
CR357397
The nursery size was slowly shrinking until it was almost zero. Eventually, the young collection stops reclaiming any space at all, although no old collection is triggered. Thus, the JRockit JVM just continues to do young collections. This has been fixed.
CR355985
After upgrading from an earlier version of the JRockit JVM to R27.4, some users experienced a change in class loader behavior: a NoClassDefFoundError was thrown if the $Inner class was not present in the CLASSPATH. This has been fixed.
CR355465
An operating system bug in some operating systems caused signals to get lost if they were sent at the exact time of a call to pthread_create. This could cause the JRockit JVM to hang. This has been solved by blocking those signals when calling pthread_create.
CR355117
On previous versions of the JRockit JVM, setting back the system clock would cause calls to Thread.sleep to sleep longer than intended. This has now been fixed.
CR330541
The new fontconfig.properties file for CJK (Chinese, Japanese, Korean) locales compatible with RHEL 5 and Asianux 3.0 has been fixed by backporting the fix from Oracle JRockit JDK 6 to Oracle JRockit JDK 5.0. This is a backport of a fix for the problem reported by Sun in
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2149631.
CR328979
In versions R27.1 to R27.5 of JRockit JVM, delay slot scheduling issues on SPARC resulted in crashes during garbage collection. This has been fixed.
CR236722
The JRockit JVM is more robust when handling JNI threads which have terminated without calling DetachCurrentThread. The JVM will now try to detect these threads and ignore them. The JRockit JVM will print a warning message when this happens to alert developers to the problem. However, note that by not calling DetachCurrentThread, the JNI API is violated, and even though The JRockit JVM is now more robust, it can never guarantee the stability when the API is violated in this way.
Changes in the Oracle JRockit JVM R27.5
Table 2-12 lists changes in this version of the BEA JRockit JVM.
Table 2-12 Changes in the BEA JRockit JVM R27.5
Issue ID
Description
CR359828
In earlier versions of Oracle JRockit, the value for Heap Usage Before for a garbage collection in a JRA recording was incorrect, as it actually showed the Heap Usage After for the proceeding collection instead. This is now fixed.
CR358662
Oracle JRockit would occasionally crash during optimization of methods containing two or more different chains of String object concatenations. This has been fixed.
CR356984
A bug was causing code optimization to crash in function _irTypesIsExactClass. This has been fixed.
CR354539
Oracle JRockit was occasionally leaving sockets in a CLOSE_WAIT state on Windows when using java.nio channel selectors. This has been fixed.
CR354463
Two threads calling getThreadInfo or getStackTrace on each other was causing Oracle JRockit to deadlock. This has now been fixed.
CR352232
The command line option
-XlargePages now can use the parameter exitonfailure=false to override its default behavior and force the JVM to exit if enough large pages can't be acquired; for example:
-XlargePages:exitOnFailure=true
CR350569
On some occasions, calling inflate on a closed Inflater would make BEA JRockit crash, creating a core file. Now, JRockit will instead throw a NullPointerException.
CR350009
The verbose module referents (with the alias verboserefs) has been replaced by the new refobj module. Using -Xverbose:refobj will provide simpler but, performance-wise, cheaper statistics about reference objects. An output similar to the detailed output from the old referents module is provided by -Xverbose:refobj=debug. Please note that this output, like the old referents module, is performance-wise very costly.
If you use the old referents module, it will be converted into refobj=debug.
CR349794
The crash dump summary now includes more detailed information on the memory system.
CR348007
A mistake in the heuristics for heap expansion that caused Oracle JRockit to throw an Out of Memory error when it should have expanded the heap has been fixed.
CR347294
A direct link has been added from crash files to the Oracle JRockit documentation. Now, if Oracle JRockit crashes, you can click this link to open the troubleshooting documents.
CR346988
A bug in the stack trace printing code caused Oracle JRockit to crash in some circumstances when printing stack traces. This happened regularly when starting WebLogic Server with -Xverbose:exceptions=debug. This has been fixed.
CR345875
Calling RetransformClasses via JVMTI would sometimes fail with error code JVMTI_ERROR_INVALID_CLASS_FORMAT. This condition has been fixed.
CR345588
The JMAPI call com.bea.jvm.GarbageCollector.hasCompaction() returned incorrect values. This has been fixed.
CR345574
If Oracle JRockit was started with -Xcheck:jni and a thread reference passed into a JVMTI callback function was used in a JNI call, the JVM would exit with an error saying [ERROR][native ] Invalid reference. This has been fixed.
CR344773
In some reports generated by the -Xgcreport flag, garbage collection pauses would sometimes appear to be longer than the garbage collection itself. This has been resolved.
CR342358
The minimum pause target limit has been lowered to less that 5 ms. The actual minimum target depends upon the application you are running.
CR340660
Calling the methods isLoaded(), load() or force() in java.nio.MappedByteBuffer on an empty buffer would throw an IOException. This has been fixed.
CR340016
In R27.5 the generation of exception stacktraces has been changed to always include the full stacktrace, regardless of whether the exceptions were generated asynchronously (NullPointerException, StackOverflowError, etc) or lazy stacktraces is on.
As a consequence of this, the verbose module stackoverflow has been deprecated and is now a no-op. This module will be fully removed in the next major release.
CR339531
For some customers using BEA JRockit R27.3.1, AssertionError: unused was thrown. This happened because the ClassLoader was fed class/package names in the wrong format. Instead of receiving com.bea.MyClass it received com/bea/MyClass. This has been fixed.
In R27.1, the class bytes preprocessing facility was changed to allow for recursive preprocessing. This meant that a classpreprocessor instance that was currently doing class preprocessing and through this caused a new class to be loaded would be recursively called with the new classbytes. This caused failures in some existing preprocessor implementations that relied on the old pre-27.1 behavior. In R27.5, this has been reverted. A thread doing class preprocessing will now silently refuse to preprocess any types created by executing the preprocessor itself.
CR335834
Because of the much larger amount of suspensions that lazy unlocking introduces, Oracle JRockit users running on Windows IA64 were often bumping into the GetThreadContext bug. Lazy unlocking is now enabled by default in the Java 6 version of BEA JRockit R27.5 on all platforms except IA64 and for all garbage collection strategies except the deterministic garbage collector. In older releases you can enable lazy unlocking with the command line option -XXlazyUnlocking.
CR335688
The garbage collection strategy is now correctly reported when a static concurrent garbage collector uses a parallel mark or sweep phase as an emergency action when the heap has become full before or during garbage collection.
-XXdisableGcHeuristics now disables all strategy changes, including emergency parallel mark or sweep in the static concurrent garbage collectors.
CR333688
In R27, a bug was introduced that would cause memory leaks whenever a JVMTI agent with the can_retransform_classes capability replaced byte code of a class being loaded. This would also impact byte code preprocessing done through the JRockit Management API (JMapi). This bug has been fixed in R27.5.
CR329800
JRockit Mission Control 3.0 did not properly detect license errors from JRockit R27.3.0 when starting a JRA/LAT recording or opening Memleak. This has been fixed.
CR328964
-XXcompactSetLimitis now always respected. Note however, that this only applies to references outside the compaction area. The number of references inside the compaction area is not limited by this flag.
CR325082
A rare occurrence in the register allocation code was causing Oracle JRockit to crash. This has been fixed.
CR306735
Oracle JRockit will no longer accept memory sizes that are larger than the address space on the current platform. In practice, this means that on a 32-bit system, the value given to -Xmx, -Xms and -Xns cannot be larger than 4 GB, or Oracle JRockit won’t start.
R27.3.1 Umbrella Patch for WLS 10.0 MP1 Now Available
An umbrella patch of Oracle JRockit JVM R27.3.1 has been built for distribution with WLS 10.0 MP1. You can download this patch as a zip (Windows) or tar.gz (Linux) file from
commerce.bea.com.
The patch include fixes for the CRs listed in Table 2-13:
Table 2-13 Changes in BEA JRockit JVM R27.3.1 CP
Issue ID
Description
CR344232
On some rare occasions, Oracle JRockit would crash when allocating memory. This only happened when a call to mmAllocObjectOrArray tried to allocate largeObjectlimit bytes that were exactly the same size as the TLA fetched.
CR339531
Disabling assertions did not work for ClassLoader-managed assertions. This could result in Assertion Errors when starting WLS in debug mode. The reason for this was that the ClassLoader was fed wrong class/package names. This has been fixed.
Note:
This issue has been resolved in Oracle JRockit R27.3.1 CP but not in Oracle JRockit R27.4. It will be fixed in Oracle JRockit R27.5, scheduled for release in early 2008.
CR336511
A patch has been built and backported for all publicly known security issues in Oracle JRockit R27.3.1. This fix corresponds to the security issues in BEA Security Advisory BEA07-177.00 and BEA07-178.00.
CR331724
When running AquaLogic Service Bus SFTP tests, BEA JRockit was creating regular core dumps. This issue occurred when two mutually exclusive code paths doing an arraycopy to the same to-array were both subject to an erroneous optimization.
CR328154
In some Solaris environments, BEA JRockit was unable to detect the number of sockets, cores and hardware threads. This caused the JVM to abort during start up and display error message:
[ERROR] Fatal error in JRockit during memory setup phase.
This situation would occur in a local zone associated with a subset of all available processors. This issue has been resolved.
CR326728
A customer experienced a system crash in mmListAddLast. This has been fixed.
Changes in the Oracle JRockit JVM R27.4
Table 2-14 lists changes in this version of the BEA JRockit JVM.
Table 2-14 Changes in the BEA JRockit JVM R27.4
Issue ID
Description
CR345588
The JMAPI call com.bea.jvm.GarbageCollector.hasCompaction() was returning incorrect values. This has been fixed.
CR345574
If the JVM was started with -Xcheck:jni and a thread reference passed into a JVMTI callback function was used in a JNI call, the JVM would exit with the error [ERROR][native ] Invalid reference. This has been fixed.
CR336996
In earlier versions of Oracle JRockit, calling the JVMTI function IterateOverHeap with JVMTI_HEAP_OBJECT_TAGGED and then JVMTI_HEAP_OBJECT_UNTAGGED would sometimes report more objects than doing IterateOverHeap with JVMTI_HEAP_OBJECT_EITHER. This has been fixed.
CR336790
Modifying a next pointer through reflection was causing a memory leak when processing phantom reference objects. This has been fixed in this version of Oracle JRockit.
CR336285
Sometimes the OS would fail to suspend a thread, which lead to Oracle JRockit crashing and throwing an EXCEPTION_ACCESS_VIOLATION error. This is now fixed.
CR334151
In earlier versions of Oracle JRockit, the JVM could hang while doing a Latency Analysis Recording and recording a park event. This has been fixed.
CR332182
In earlier versions of Oracle JRockit, the java.lang.management.ThreadInfo API and the JVMTI functions GetOwnedMonitorStackDepthInfo and GetOwnedMonitorInfo did not return monitors that had been entered by calling the JNI function MonitorEnter. This has been fixed.
CR332016
In some cases when allocation of a large array failed, the JVMTI ResourceExhausted event was not sent. This has been fixed.
CR332012
In earlier versions of Oracle JRockit, the jvmtiHeapReferenceCallback callback function was sometimes called with the wrong class_tag parameter. This has been fixed.
CR332002
In earlier versions of Oracle JRockit, the JVMTI functions FollowReferences and IterateThroughHeap did not respect the klass parameter. This has been fixed.
CR331991
In earlier versions of Oracle JRockit, the JVMTI function GetClassVersionNumbers did not return JVMTI_ERROR_ABSENT_INFORMATION for primitive and array classes. This has been fixed.
CR331724
When running AquaLogic Service Bus SFTP tests, Oracle JRockit was creating regular core dumps. This issue occurred when two mutually exclusive code paths doing an arraycopy to the same to-array were both subject to an erroneous optimization.
CR328924
Oracle JRockit no longer fails the Java Language Specification requirement on unique references for boxed integers in the -128 to 127 interval.
CR328368
Allocation prefetch has been enabled by default on AMD’s Opteron architectures.
CR328154
In some Solaris environments, Oracle JRockit was unable to detect the number of sockets, cores and hardware threads. This caused the JVM to abort during start up and display error message:
[ERROR] Fatal error in JRockit during memory setup phase.
This situation would occur in a local zone associated with a subset of all available processors. This issue has been resolved.
CR327167
The JVMTI ClassPrepare event was previously dependant on class initialization order and thus subject to user class hierarchy design. In R27.4 this has changed so that ClassPrepare is always sent according to specification.
CR321557
The experimental and unsupported API GCControl, containing the methods
Call profiling is an optimization feature known to provide significant benefit to many workloads, including the SPECjbb2005 benchmark. Up until Oracle JRockit R27.1, you could enable this feature by using the -XXaggressive command-line option, but it was removed from the flag in R27.1. As of Oracle JRockit R27.4, you can enable call profiling by using the
-XXcallProfiling command-line option.
CR318629
Due to a bug in the attach framework (Sun bug #6559427), Mission Control was leaking several handles per locally-running JVM (JVM running on the same machine as Mission Control is) every time a Mission Control polls for locally running JVMs. This has been fixed in R27.4.
CR311802
Some customers experienced linked lists breaking, which would result in leaking objects caused by a modification of next pointers through reflection. This is now fixed.
CR304741
This version of Oracle JRockit has two new Long perf variables:
jrockit.gc.oc.compactionInternalCount
jrockit.gc.oc.compactionExternalCount.
These variables count the number of internal and external compactions, respectively. They both sum up to the previously existing jrockit.gc.oc.compaction.no value.
CR104868
A rewrite of an internal code generation framework for R27.4 has eliminated known bugs that were causing Oracle JRockit to crash.
Changes in the Oracle JRockit JVM R27.3
This section lists changes and known issues in the BEA JRockit R27.3
Known Issues in the BEA JRockit JVM R27.3.1
Table 2-3 lists known issues in this version of the BEA JRockit JVM.
Table 2-15 Known Issues in the BEA JRockit JVM R27.3.1
Issue ID
Description
CR336813
Oracle JRockit might sometimes incorrectly optimize loops, assigning the same negative value to all elements of an array.
CR331774
If you are running on Linux or Solaris and press Ctrl-C to properly shut down your application, it will actually terminate immediately and you risk losing any runtime data that hasn’t been saved to disk or a database. This happens because Oracle JRockit fails to register the SIGINT signal handler used for the shut down hooks.
Workaround:
If you encounter this problem, please download the updated version of the product, R27.3.1 from the BEA Downloads page at:
This issue does not apply to applications running on Windows.
Changes in the BEA JRockit JVM R27.3
Table 2-16 lists changes made in this version of the Oracle JRockit JVM.
Table 2-16 Changes in BEA JRockit JVM R27.3
Change Request ID
Description
CR329414
Oracle JRockit could, in rare cases, garbage collect an instance declared as final on which the application has made the instanceof operation on. This would result in a NullPointerException in the application.
JRockit could crash due to stack overflow while optimizing very large methods. This has now been fixed.
CR323086
JRockit gave unexpected errors with the -Xcheck:jni command-line option. JRockit would detect a false positive when using JNI to do a downcast array assignment (assign an array of subclass to Object as element to an array of Object arrays, i.e set [byte -> [[Object).
CR322633
JRockit sometimes could not load very large jsp classes, which resulted in the error:
This error was caused by that JRockit used a limit of 65536 on the SourceDebugExtension attribute. This limit has now been removed.
CR322146
The garbage collector mode -XgcPrio:pausetime now uses a fixed nursery of the same size as -Xgc:gencon, which is 10MB times the number of hardware threads.
CR321899
When using the parallel garbage collector and if an evacuation was aborted because the time limit was reached, the evacuation area size was doubled. This bug could cause unnecessary long pause times in the parallel garbage collector. This has now been fixed.
CR321325
The JVMTI function GetAllStackTraces previously returned JVMTI_ERROR_ILLEGAL_ARGUMENT if the max_frame_count parameter was 0 (zero). This has now been fixed.
CR319804
The JVMTI function GetObjectMonitorUsage could return JVMTI_ERROR_THREAD_NOT_ALIVE if the thread holding the object terminated during the call. To comply with the specification, this has now been changed to return JVMTI_ERROR_NONE and set info_ptr->owner to NULL instead.
CR319764
JRockit now handles names that are as long they are allowed by the ZIP standard. The previous limitation of maximum 512 bytes long entry names in zip files no longer exists.
CR319239
JRockit did not always find all free memory in the fourth GB of the virtual memory space. This bug manifested on 64 bit Linux platforms and could lead to OutOfMemoryErrors when using a maximum java heap size between approximately 3 and 4 GB. This has now been fixed
CR319234
The JMAPI getProcessAffinity/suggestProcessAffinity now works correctly when running on a Linux system with a GLIBC version older than 2.3.4.
CR317171
Pause time measurements between R27.3 and earlier JRockit releases (except for JRockit R27.2) are now comparable.
CR317113
JRockit now reports the correct amount of physical RAM in 32 bit machines with PAE extension and more than 4GB of RAM installed.
CR316942
JRockit no longer hangs if you specify a nursery size (-
Xns) that is less than 18 times the thread-local area size (
-XXtlaSize).
CR315905
The Mercury Profiler tool has been omitted as of this release.
CR315761
It is now possible to use the EPollSelectorProvider in java.nio on Linux ia64.
Note:
The EPollSelectorProvider is only used if the system property java.nio.channels.spi.SelectorProvider has been set to sun.nio.ch.EPollSelectorProvider.
CR314598,
In JRockit R27.1 and R27.2, when trying to run some MBean servers, some classes could not be found, even though they were on the classpath. This problem has now been fixed.
CR314527
Previously, on rare occasions, external compaction caused very long pause times (if the heap was fragmented) when trying to move a large object from the highest heap parts. This has now been fixed.
CR314031
JRockit no longer calculates the wrong serialVersionUID for some classes backported from JDK 5 to JDK 1.4 where Enums is used. Enums are now correctly ignored (they are not part of the 1.4 specifications) when calculating the serialVersionUID for 1.4.
You start a local in-memory connector if start without any arguments.
You start a remote connector if:
Any of the options authenticate, ssl, port, or autodiscovery is set.
Any of the above options is set through system or management properties, (com.sun.management.jmxremote.port, jrockit.management.port, etc.).
The password file, pointed to by the management property com.sun.management.jmxremote.password.file (default jmxremote.password), exists.
The remote connector requires that you have username and password defined in the above password file unless the option authenticate is set to false.
The remote connector uses SSL by default, unless the option ssl is set to false.
CR312194
To see the version of the time zone data (tzdata) of a JRE you can now run:
<jdk>\bin\tzinfo
The output shows Java version, JRE version, and Time Zone data (tzdata) version.
CR311518
The default TLA size now grows more aggressively and it has been increased to 2k at a 16Mb heap up to 256k at a 2GB heap.
CR311336
This release offers a new heuristic for updating the nursery size (for the static garbage collector) during runtime.
CR311327
The value for TotalGarbageCollectionTime is now showed in milliseconds on Windows XP.
CR293617
Singlestepping with JDI on a single-CPU computer is now faster and easier to use.
CR262438
JRockit no longer fails to detect whether HyperThreading (HT) has been enabled or not, which means that it will no longer start a non-optimal number of garbage collection threads.
CR206755
The initial heap size will now be at least twice the size of the nursery if -Xns (the nursery size) is set and -Xms (the initial heap size) is not, unless this leads to that the initial heap size becomes larger than the maximum heap size.
Changes in the Oracle JRockit JVM R27.2
Table 2-17 lists changes made in this version of the Oracle JRockit JVM.
Table 2-17 Changes in the BEA JRockit JVM R27.2
Change Request ID
Description
8139785
On Microsoft Windows Server 2003 “R2”, Oracle JRockit R27.1 fails to escape the quotation characters around the word R2 when writing the operating system name to a JRA recording. This breaks the XML-structure of the recording and causes problems when reading the recording. To make the recording readable, manually remove the quotation marks around R2 in the operating system name field of the recording file (a text search for the four characters “R”' in the recording's XML-file should find it). This problem has been fixed in JRockit version R27.2 and later.
CR315538
Problems were occurring because the JRA was unable to handle class unloading. This situation has been corrected.
CR311708
Oracle JRockit no longer detects false positive Java deadlocks.
CR311186
A regression in BEA JRockit R27.1 caused -Xverbose output to be buffered and therefore delayed. The output is no longer delayed.
The JNI method ToReflectedMethod crashed if the class parameter was NULL. This has now been fixed.
CR308967
Sometimes BEA JRockit crashed when the method java.util.concurrent.atomic.AtomicReferenceArray.compareAndSet was called. This has now been fixed.
CR308312
The byte code verification in BEA JRockit has been relaxed in cases where JRockit’s strict byte code verification would otherwise cause ClassFormatErrors to be thrown.
CR307903
If a thread was interrupted for garbage collection while copying an array, the garbage collection could result in long pauses. This has now been fixed.
CR307114
When reflection was used to set volatile static variables in JRockit on Windows, JRockit crashed. This has now been fixed.
CR306848
The jstat tool (in the /bin directory) used counters that triggered error messages about Unresolved Symbols. This has now been fixed and jstat no longer uses the obsolete counters.
CR306729
The heuristics used by -Xgcprio:throughput to set nursery size and select garbage collector strategy have been improved.
CR306048
The referrer_index argument to the jvmtiObjectReferenceCallback function was not always set to -1 when it should have been. This has now been fixed.
CR305091
The jrcmd utility on ia64 had problems with user names longer than 9 characters. This has now been fixed.
CR304733
BEA JRockit’s method profiler timing counters are no longer available on Fujitsu’s SPARC implementation SPARC64, since JRockit sometimes gave the wrong timing data (negative numbers) on that platform.
CR304335
The method getNurserySize() in the GarbageCollector class now works as documented, that is, it throws a NotAvailableException when the JVM is running a single-spaced garbage collector (without a nursery). Previously, the method returned 0 (zero).
The method setNurserySize() now throws a NotAvailableException when the JVM is running a single-spaced garbage collector.
CR303790
The new command line option -XX:MaximumNurseryPercentage limits the maximum size of the nursery to a percentage of the free heap space available after the latest old collection. The default value is 95%.
CR302924
A ctrl-break handler can now be sent to stop a JRA recording even if JRA has not actually started recording yet (but is in a start up state). If JRA has just been started, then there may be a short delay before the recording is actually stopped.
Previously, if you sent a ctrl-break handler to stop JRA before it had actually started recording, you would have generated the following error message:
Error: No JRA recording running.
CR301964
Issues with thread names not being available in Linux environments are fixed.
CR299662
The parameters genpar and singlepar have been added to the -Xgcoption. Using -Xgcwith these parameters are equivalent to using the -XXsetgc option with the parameters genparpar and singleparpar.
CR299651
The option -XlargePages has been added. This option is intended to replace -XXlargePages but the old command-line option is retained for backward compatibility purposes.
CR298847
At all times, the following relations are now automatically maintained between minimum and preferred TLA size, large object limit, and minimum block size:
If you set two or more of the options, then you must make sure that the values you use fulfil these criteria. If you only set one of the options, the others will adapt if necessary so that the values are valid.
It is recommended that you primarily set the TLA size parameters for memory management tuning purposes, while letting BEA JRockit automatically adjust the large object limit and minimum block size. By default, the large object limit will be set to whichever is the lower value of (1) the minimum TLA size and (2) the preferred TLA size divided by 2. The default minimum block size is 2k.
CR297814
The limit of capturing only the first 20 frames of allocation stack traces in the Memory Leak Detector has been removed.
CR278996
-Xverbose:referents (alternatively, -Xverbose:verboserefs) gives you printouts of all reference objects for each old generation garbage collection as well as the referents to which they point. In previous BEA JRockit versions, this could be achieved with the option -Djrockit.verboserefs.
Changes in the Oracle JRockit JVM R27.1
Table 2-18 lists changes made in this version of the Oracle JRockit JVM.
Table 2-18 Changes in the BEA JRockit JVM R27.1
Change Request ID
Description
CR266204
Optimized method calls on null objects now throws NullPointerException as is the expected behavior.
CR264251
The JRockit installer on Windows previously only had an “Install Public JRE” option on 32-bit Windows. This option is now also available with the 64-bit JRockit versions for Windows (x86-64 and Itanium).
CR274190
The command-line option -Xverbose:gcpause has been improved, see
-Xverbose in the Oracle JRockit Reference Manual for more information.
CR276950
JRockit R27.1 and later no longer supports Linux versions using the old LinuxThreads library, which includes Red Hat AS 2.1, SuSE ES 8.0, and other distributions based on the standard 2.4 kernel. See the Supported Configurations documentation for information on supported releases.
CR277922
It is now possible to install both the 32-bit and the 64-bit BEA JRockit JDK/JRE on Windows x86_64, side by side.
CR280059
JRockit no longer generates faulty machine code for Java code that stores the >this< pointer into its own object. This caused Java variables to be set to zero in rare situations.
CR281323
Internal JVM threads in the “system” ThreadGroup did not have the correct value for isDaemon() and getPriority(). This has now been fixed.
CR281936, CR283237
Previously, if the memory was very fragmented when JRockit started, JRockit crashed during startup without creating any dump file. This problem is now fixed.
CR283236
The behavior of java.lang.StackTraceElement has been changed to conform to that of the Sun reference implementation. In previous releases the method signature was included in the resulting String, while the new version behaves as described in:
This also affects the behavior of Throwable.printStackTrace(), in that the result will not list any method signatures.
CR283454, CR283915
Previously long thread sleeps issued by Thread.sleep(...) and Object.wait(...) could end too early if the sleeps were longer than 0x3FFFFFFF milliseconds (approximately 12.4 days). This problem has now been fixed.
CR284604
The JVMTI API version of the Java SE 5.0 version of JRockit R27.1 is 1.1. This can be seen with the GetVersionNumber API function. Some capabilities of JVMTI 1.1 are not available in the Java SE 5.0 version of JRockit.
CR286267
Previously an uncommon internal deadlock could occur. In the stack traces of a thread dump, the deadlock situation may have had calls that had to do with class loading.
CR286625
The BEA standalone installer filenames for Windows platforms have changed names. Now “windows” is used instead of “win” to name the target operating system in the platform part.
CR286926
Command line option verification has become stricter and you will receive more comprehensive error messages and warnings when using command line options that are incorrect. See the Oracle JRockit Reference Manual for details.
CR291898
JRockit could in rare circumstances crash when compiling methods calling String.indexOf(). This has been fixed.
CR291969
JRockit no longer crashes due to a previous bug in the JRockit code optimizer that was triggered by applications throwing a large amount of exceptions.
CR294608
By default, the output from
-Xverbose now includes the logging level as well as the module. Use -XverboseDecorations to change the default settings.
CR296429
The JMAPI function JVM.getProcessAffinity() now works properly on Linux.
CR296668
A bug that caused JRockit to crash in the internal function handlersMatchExceptForUnlockHandler has been fixed.
CR297036
The Security Vulnerability in RSA Signature Verification issue, Sun Alert ID 102686, fixed in Sun JDK 1.4.2_13 has been back ported to JRockit 1.4.2_12 R27.1.0.
CR297037
The Security Vulnerability in RSA Signature Verification issue, Sun Alert ID 102686, fixed in Sun JDK 5.0 update 9, has been back ported to JRockit 5.0 update 8 R27.1.0.
CR297675
Now JRockit shows the correct value for TotalGCTime.
The incorrect value could previously be observed through the JRockit Management API, and through the WLS Console.
CR298049
JRockit no longer crashes when compiling bytecode where normal control flow and exception control flow do not follow javac conventions. As far as BEA is aware, such bytecode is only produced by a small set of bytecode obfuscators.
CR298365
The command-line option -Xmanagement has changed behavior in this release.
CR301758
As part of the rewrite of JRCMD in R27, the <jre>/bin/jrcmd launcher has been removed (the <jdk>/bin/jrcmd still remains), i.e. the JRCMD tool is now only available if installing the full JRockit JDK, not only the JRockit JRE.
CR302559
The “Security Vulnerability in Serialization” issue, Sun Alert ID 102731, fixed in Sun JDK 1.4.2_13, has been back ported to JRockit 1.4.2_12 R27.1.
Known Issues
Table 2-19 lists issues that, in some circumstances, might affect the performance of the JRockit JDK.
Table 2-19 Known Issues in the JRockit JDK
Issue ID
Description
Untracked
For Linux users only.
The JRockit JVM is crashing due to a signal handling conflict.
If you are using the JRockit JVM in conjunction with a native library that relies on OS signals you may experience crashes due to a signal handling conflict between Oracle JRockit and the native library.
Workaround:
Set the environment variable LD_PRELOAD as follows:
Taking a LAT recording while running with a byte code modifying agent (like Wily Introscope) could lead to ClassCircularityError error or NoClassDefFoundError.
Workaround:
Run Oracle JRockit with:
-Djrockit.agent_and_lat.enable=true
This will disable agent preprocessing of latency classes as well as four classes that the latency event object depends on:
java/io/ByteArrayOutputStream
java/io/DataOutputStream
java/io/DataOutput
java/io/IOException
9258993
Using the command set_filename in a ctrlbreak.act file could cause the Oracle JRockit JVM to crash on some systems
8889334
Sometimes when trying to launch Oracle JRockit jrcmd on Windows, the command will return:
.
<pid>: Not enough storage is available to process this command
.
This happens when you try to launch jrcmd in a different Windows station from the one on which the target JVM is running. This can occur, for example, when trying to use jrcmd in a Terminal Services environment or if the JVM is running as a Windows service. jrcmd does not support communication between Windows stations. To avoid this situation, ensure that jrcmd is launched on the same Window station as the target JVM process.
8418795
When Oracle JRockit is running on OEL on OVM, a fix is required in OEL. Listed below are the minimum requirements for running JRockit on OEL on OVM:
OVM 2.1.2
OEL 4.7 ia32
Patch required. The para-virtualized kernel for OEL needs to be 2.6.9-78.0.13.0.1.1.ELxenU or later.
OEL 4.7 x64
GA bits works fine
OEL 5.3 ia32 and x64
GA bits works fine
JRockit supports both hardware and para-virtualized versions and both OEL 4 and OEL 5.
Note:
This issue was also tracked as bug 8324323.
8271382
JVMFactory.getJVM().getMachine().getPhysicalMemory().getUsedMemory() will return 0 if run on a 64-bit machine with a 32-bit JRockit instance.
CR378758
In rare cases, a faulty code optimization will make multiplying the results of two function calls with the double return type into a new double value generate an incorrect result.
CR372377
Sometimes, when debugging the throwing of an uncaught java.lang.ClassCastException with Eclipse, the debugged JVM might crash.
CR371381
The JRockit JVM is incompatible with Sun HotSpot when serializing java.math.BigDecimal objects over IIOP.
CR364607
Supplying a file name (including path) the length of which exceeds 256 characters to the java.util.zip.ZipFile constructor on Windows will fail and throw a java.io.FileNotFoundException even if the file exists.
CR363637
The JRockit JVM might occasionally crash in the pkcs11_softtoken.so native library.when executing AES cryptography code. This is due to a bug in Solaris versions 10.4 and earlier. The bug has been fixed in Solaris 10.5.
CR363487
Due to an issue with 64-bit Windows Vista/2008, if you try to install the 64-bit JRockit JVM in the standard folder, you’d be told the installer cannot write there; however if you chose to install to another folder (one that the installer can write to), the files are copied and then the installer tries to write the uninstaller information and fails. The result is a broken installation without a working uninstaller.
Workaround:
Right-click on the file and select Run as administrator when installing the JRockit JDK.
Note:
This issue has been fixed in Oracle JRockit R27.6.
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:
When debugging Java floating point applications on SSE2-enabled platforms (supported on Pentium 4 or newer and AMD Opteron, Athlon 64 from 2003 or later processors) using a 32-bit version of the JRockit JVM on Windows Vista x64, local floating point variable values might be bogus. This is due to a bug in Windows Vista x64. It has been fixed in Windows Vista x64 SP1.
CR359954
In JRockit Mission Control released with Oracle JRockit JVM R27.4, the value shown in Heap Usage Before for a garbage collection in a JRA recording is incorrect. The value shown is actually the value of Heap Usage After for the proceeding collection. This will be fixed in Oracle JRockit JVM R27.5.
CR359328
The ACL on the per-user hsperfdata_<user> directory might cause administration problems on some systems. One example of the problem is that the files under the directory can be removed by a user with Administrator privileges but the directory itself cannot.
Workaround:
Logged in as Administrator, modify the ACL with the cacls command before attempting to remove it.
CR357402
If a Java program uses too many (currently 2097151) active monitors (that is, by doing wait/notify or contended synchronization on too many objects) the JVM’s internal monitor index can overflow. This is more likely to happen when using large heaps and few garbage collections occur. If this happens, the JVM will crash with an error saying “The number of active Object monitors has overflowed.”
CR349882
JRockit JDK installation and the use of applications on compositing window managers under Linux may fail with the following error message: xcb_xlib.c:50: xcb_xlib_unlock: Assertion 'c->xlib.lock' failed. This is due to a known problem in the native Sun JDK libraries; see
Sun Bug 6532373.
This issue has been fixed in Oracle JRockit 5.0 R27.6.3 and Oracle JRockit 6 R27.6.3.
CR348820
Debugging a Java program when running the JRockit JVM with hardware performance counters on IA64 (
-XXhpm) can result in exceptions. This is because the implementation of the hardware performance counters uses signals to communication with the JVM and the debugger agent implementation (JDWP) does not correctly handle this.
Workaround:
Disable hardware performance counters when debugging.
CR341568
The JRockit JDK exposes Mbeans under the bea.jrockit.management domain, accessible through the Management Console. These MBeans are proprietary and subject to change at any time. While you can access these MBeans directly using other JMX based tools, such direct access is not supported by Oracle.
CR341293
With Oracle JRockit R27.1 and later, JVMPI and JVMTI agents cannot be used at the same time. If you attempt to do this, only the transformations applied by the JVMPI agent are processed. The workaround is to use only one of these two interfaces, with a preference for JVMTI since JVMPI has been deprecated as of J2SE 5.0.
CR340838
When starting the JRockit JVM with a maximum heap size larger than the maximum address space (4 GB) on Linux ia32, the JVM might crash, instead of terminating nicely and generating an error message, as it should.
CR340660
Calling the methods isLoaded(), load() or force() in java.nio.MappedByteBuffer on an empty buffer throws an IOException instead of silently returning. This is know to affect the IntelliJ IDEA IDE.
CR339469
Copying event information from the Thread Latency Log table to the clipboard does not work properly. Only the header information will be copied. This issue will be fixed in the Mission Control included in JRockit JVM R27.5.0.
CR338731
Some events in the JRA latency recordings have their thread ID’s set to 0. In particular, this applies to JVM Event Wait->Signalling thread, Java Synchronization->Last holder thread and Java Synchronization->Holder thread.
CR338678
If you are running JRockit JDK 1.4.2, you might receive an incorrect error message when using the command-line option -Xmanagement with the parameter class, followed by additional parameters; for example:
java -Xmanagement:class=foo,ssl=false Hello
results in this error message:
Unknown parameter class Could not create the Java virtual machine
You cannot specify any parameters after the class parameter, so the correct error message should be:
Unknown parameter ssl Could not create the Java virtual machine
Compiling a program that uses the JRockit Management API (JMAPI) with javac from a Java SE 6 version of the JRockit JDK will give an error saying that “package com.bea.jvm does not exist”.
Workaround:
Do one of the following:
Delete (or rename) the file <jrockit_home>\lib\ct.sym and then recompile.
Use javac from a 5.0 version of the JRockit JDK instead.
CR337475
In a JRA recording, the number of allocated TLA (Thread Local Areas) is recorded, as well as the preferred size of a TLA (in bytes). The JRA GUI will multiply these values to get the number of bytes allocated in TLAs during the entire recording; however, the size of the TLAs actually used can sometimes be a bit smaller than the reported size (the preferred size is only a preferred size; fragmentation can cause the TLAs to become smaller) and the value printed in the GUI can be overestimated.
CR328975
Latency data in a JRA recording will be erased from the disk if comments on the Notes tab in Mission Control are saved. Non-latency data will still be available, but the message “Warning! Error(s) when reading JRA-recording” will appear.
Workaround:
Don’t use the Notes tab in Mission Control when working with recordings that contain latency data.
CR328964
The
-XXcompactSetLimit flag does not always limit the compaction set. In some circumstances compactions can exceed the given limit, typically in the initial compactions before the whole heap has been processed for external compaction.
CR328729
When starting a JRA-recording by using Mission Control, the recording might not start and the error message, “Could not delete file” will appear. This happens when the recording has the exact same filename as a previously-started recording.
Workaround:
In the JRA-recording wizard, give each recording a unique name or close Mission Control and restart it.
CR326746
The set_filename handler will not update the output for the running command batch.
Workaround:
Issue a set_filename command.
Issue the commands that you wish to send to the output.
CR322908
A known issue in Red Hat Enterprise Linux 5.0 on x86_64 with the dladdr() call in glibc might cause irregular behavior or a crash when running graphical applications; see also Red Hat Errata RHBA-2007:0619-3 at
http://rhn.redhat.com/errata/RHBA-2007-0619.html. The issue is fixed in Red Hat Enterprise Linux 5.1.
CR317171
A regression has been introduced in R27.2 in how pause times are measured. Pause times are visible in the JRockit Runtime Analyzer Tool and the verbose logs in the Mark:Final:StopThreads pause part, where they appear to be much longer than in previous JRockit JVM versions. This means that pause time measurements are not comparable between R27.2 and earlier JRockit JVM versions. The actual pause times have not changed.
Note:
This issue has been fixed in BEA JRockit R27.3.
CR316942
If you specify a nursery size (-
Xns) that is less than 18 times the thread-local area size (
-XXtlaSize), the JRockit JVM will hang without printing an error.
Workaround:
Increase the specified nursery size (using -
Xns) or lower the minimum TLA size.
As of JRockit R27.1 the format for how to specify TLA size changed to specify both minimum and preferred TLA size. The old way (
-XXtlaSize
:<size>) sets both minimum and preferred. Use -XXtlaSize:preferred to set the preferred TLA size, for example: -XXtlaSize:preferred=64k.
Note:
This issue has been fixed in BEA JRockit R27.3.
CR315939
If you are using a 32-bit JVM and set the maximum heap size to a value above 4 GB, the JRockit JVM will allocate as large a heap as possible, but not exceeding 4 GB. This can result in the JVM throwing an internal out of memory error because the heap has taken all the address space.
Workaround:
When you encounter this situation, reduce the heap to a value less than 4 GB.
CR315761
It is not possible to use the EPollSelectorProvider in java.nio on Linux ia64 with JRockit 5.0 R27.2. Note that the EPollSelectorProvider is only used if the system property java.nio.channels.spi.SelectorProvider has been set to sun.nio.ch.EPollSelectorProvider.
Note:
This issue has been fixed in BEA JRockit R27.3.
CR312235
The code garbage collection is disabled during JRA recordings, so you might in special (rare) circumstances see an increased use of native memory during recordings. This can happen if you load a lot of classes when you do either a very long recording (several hours or even days) or shorter recordings back-to-back.
Workaround:
The workaround is to do several recordings, but leave some time (a few minutes should suffice) between JRA runs, so the JVM can run the code garbage collection.
CR311188
On Solaris 10, a bug that makes getrusage return bogus values in turn causes all printouts of page faults to present bogus values. You may get these printouts when you, for example, use
-Xverbose:memory.
A known issue in Sun’s J2SE 5.0 update 11 might cause BEA JRockit to dump when PrinterJob.printDialog() is called from a sub-thread. BEA has only identified the bug using Windows Vista on the IA32 architecture. This known issue will be fixed in 5.0 update 11 and included in JRockit R27.3.
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.
If you are using the JRockit JDK on the Itanium version of Windows Server 2003 and the Java application unexpectedly hangs during heavy system load, then it might mean that the JVM has triggered an operating system bug. At the OS level, this is manifested as the JRockit JVM blocking on a call to the Windows GetThreadContext function. Microsoft has posted a knowledge base article that also includes instructions for obtaining a hotfix for the problem. It is available at http://support.microsoft.com/kb/947504.
CR305091
The jrcmd utility can have problems on ia64 if your username is longer than 9 characters. This is not a problem on other platforms. The issue has been fixed in BEA JRockit R27.2.
CR304556
If the JRockit JVM is started with a minimum TLA size (
-XXtlaSize:min=X) that is larger than the maximum specified heap size (
-Xmx), JRockit will deadlock at startup and never start running.
Workaround:
Set a minimum TLA size that is less than the maximum heap. Typically, the TLA size should be much smaller than the heap size.
CR304335
In R27.1, the JMAPI method getNurserySize() in the GarbageCollector class doesn’t work as documented. If the garbage collector that the JVM is running isn’t using a nursery, the method should throw a NotAvailableException. Instead it returns 0. This has been fixed in R27.2.
Workaround:
If you depend on the exception being thrown, e.g. checking if you use a nursery or not, you can work around the problem by both catching the NotAvailableException, as well as checking the return value and see if it returns 0. If it throws an exception, or returns 0, a nursery is not being used.
CR302141
Files containing JRA recordings can be dragged and dropped into JRockit Mission Control. However, when dropping multiple files, some open file tabs may be labeled “JRA Editor” instead of the actual file name.
Workaround:
Select a tab for the file, then the file is actually read and the label is set to the correct file name.
CR300393
If the nursery is too small, JRockit may get stuck in triggering young collections, “back to back”, without promoting anything. This can be seen in the
-Xverbose:memdbg outputs as repeated young collections where the number of promoted objects is zero. It can also be seen as very short times between the young collections (close to 0 ms).
Workaround:
Increase the nursery size. If nursery size has been set automatically by
-Xgcprio:throughput, it can be overridden by manually setting
-Xns to a higher value.
CR300097
A known issue in Red Flag 5.0 with the wait() call might cause irregular behavior or crashes for Red Flag customers using this OS version. This has been fixed in AsianUX 2.0 SP1 (of which Red Flag 5.0 is a part) and we strongly recommend that our users upgrade their OS to resolve this issue.
CR295457
If an application is configured with a heap size close to 4 GB and includes a lot of classes, an out of memory situation might occur if some JVM internal structures and the Java heap both try to share the low 4 GB memory space of the process. If this happens, try to increase or decrease the Java heap size by using either the
-Xmx option or disable compressed references by using the
-XXcompressedRefs=0 option.
CR284519
To use the
-XXmme option on Red Hat Enterprise Linux 4.0 you need to have Red Hat Enterprise Linux 4.0 QU4 or a later release installed; otherwise, you might encounter sporadic crashes.
CR283776
In 5.0 Update 7, Sun changed the serialVersionUID for the javax.xml.namespace.QName() class due to a historical defect. For the original bug report, see CR6267224 in Sun's bug database at:
In case the JRockit JDK installer *.bin fails immediately with the same error message as above, you can work around it by unpacking the installer program manually, applying the following patch (Listing 2-2) to the internal JRE, then starting the installer yourself in GUI mode using the patched internal JRE.
