For information on new features and resolved issues in the associated version of Oracle JRockit Mission Control (version 3.0.3), please refer to the Release Notes for that product 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
Note:
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 BEA 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 BEA JRockit JVM R27.4
BEA 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 BEA 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 BEA 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
BEA 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 BEA 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 BEA 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 BEA JRockit R26.4 and BEA 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 BEA JRockit R26.4 and BEA 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 BEA JRockit R27. For a description of any new option, please refer to the specific option in the BEA 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 BEA JRockit to print out an error message and terminate. Please refer to the specific option in the BEA 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 this version of the Oracle JRockit JVM.
Table 2-3 Changes in the Oracle JRockit JDK R27.6
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 BEA JRockit JVM R27.5
Table 2-4 lists changes in this version of the BEA JRockit JVM.
Table 2-4 Changes in the BEA JRockit JVM R27.5
Issue ID
Description
CR359828
In earlier versions of BEA 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
BEA 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
BEA 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 BEA 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 BEA 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 BEA JRockit documentation. Now, if BEA JRockit crashes, you can click this link to open the troubleshooting documents.
CR346988
A bug in the stack trace printing code caused BEA 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 BEA 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, BEA 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 BEA JRockit to crash. This has been fixed.
CR306735
BEA 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 BEA JRockit won’t start.
R27.3.1 Umbrella Patch for WLS 10.0 MP1 Now Available
An umbrella patch of BEA 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-5:
Table 2-5 Changes in BEA JRockit JVM R27.3.1 CP
Issue ID
Description
CR344232
On some rare occasions, BEA 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 BEA JRockit R27.3.1 CP but not in BEA JRockit R27.4. It will be fixed in BEA JRockit R27.5, scheduled for release in early 2008.
CR336511
A patch has been built and backported for all publicly known security issues in BEA 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 BEA JRockit JVM R27.4
Table 2-6 lists changes in this version of the BEA JRockit JVM.
Table 2-6 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 BEA 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 BEA JRockit.
CR336285
Sometimes the OS would fail to suspend a thread, which lead to BEA JRockit crashing and throwing an EXCEPTION_ACCESS_VIOLATION error. This is now fixed.
CR334151
In earlier versions of BEA 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 BEA 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 BEA JRockit, the jvmtiHeapReferenceCallback callback function was sometimes called with the wrong class_tag parameter. This has been fixed.
CR332002
In earlier versions of BEA JRockit, the JVMTI functions FollowReferences and IterateThroughHeap did not respect the klass parameter. This has been fixed.
CR331991
In earlier versions of BEA 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, 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.
CR328924
BEA 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, 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.
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 BEA 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 BEA 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 BEA 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 BEA JRockit to crash.
Changes in the BEA 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-7 Known Issues in the BEA JRockit JVM R27.3.1
Issue ID
Description
CR336813
BEA 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 BEA 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:
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 BEA JRockit JVM R27.2
Table 2-9 lists changes made in this version of the BEA JRockit JVM.
Table 2-9 Changes in the BEA JRockit JVM R27.2
Change Request ID
Description
CR315538
Problems were occurring because the JRA was unable to handle class unloading. This situation has been corrected.
CR311708
BEA 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.
