Skip navigation.

Introduction to JRockit SDK

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

New Features in BEA JRockit SDK

BEA JRockit SDK represents a incremental step up from previous version of this SDK. Now compatible with JDK version 1.4.2, BEA JRockit contains many new features designed to improve performance and streamline operation. Note that some features provided in this version of BEA JRockit SDK are non-standard or "experimental." These features, while tested to work with this version of the SDK, are provided as-is and might change at any time.

This section includes information on the following subjects:

 


Standard Features

This section describes standard features introduced in BEA JRockit SDK. "Standard features" are fully-supported by BEA Systems and should not change without appropriate notice. These features include:

Improved IPF Performance

BEA JRockit supports Intel Corp's. Itanium Platform Family (IPF) of 64-bit processors. This version on BEA JRockit has been enhanced to improve its performance with these processors.

New Default Parameter Settings

BEA JRockit supports the -server and -client startup parameters.

Setting the JVM type (or accepting the default) will also set the garbage collection algorithm that will be used during runtime. For more information on garbage collection and the -server and -client options, please refer to Setting the Default Garbage Collector in Using BEA JRockit Memory System.

Native POSIX Thread Library Available with Linux

The Native POSIX Thread Library (NPTL) is a thread library option available for use instead of LinuxThreads with Red Hat Enterprise Linux 3.0. NPTL provides significant performance improvement for multi-threading Linux applications. For more information on NPTL, please see the white paper The Native POSIX Thread Library for Linux, by Ulrich Drepper (this file will open as a .pdf file; you will need Adobe Acrobat or comparable PDF reader to view this file).

Warning: While this NPTL is fully-supported by BEA JRockit 1.4.2_04, it is not fully supported by BEA JRockit 1.4.2_03. If you are using that version of the JVM and your system has NPTL enabled, BEA JRockit might throw an error at runtime as it will try to use this library automatically. To avoid the error, either disable NPTL by setting LD_ASSUME_KERNEL=2.4.1 in your environment or upgrade your version of BEA JRockit to 1.4.2_04.

New Heap Sizing Behavior

In BEA JRockit, automatic heap resizing behavior has been enhanced to allow more dynamic and adaptive heap usage. These enhancements are particularly evident when minimum and maximum heap sizes are not specified (the default case) but they also affect the behavior when these values are set.

Shrinking the Heap

The heap can now shrink when the system runs low on memory and BEA JRockit is using less than 50% of its heap (that is, the amount of live objects after a garbage collection is less than 50% of the heap size). In BEA JRockit 8.1 and earlier, the heap could only shrink when running with the generational copy garbage collector, which has been deprecated in BEA JRockit 1.4.2. Now the heap can shrink when running any garbage collector; however, the heap will not shrink below the initial specified size if that value (specified by -Xms:nnMB|GB) is set.

Growing the Heap

The ability of the heap to grow is now more restricted. If the maximum heap size (specified by -Xmx:nnMB|GB) is not set, the heap will not grow when the system runs out of memory if such growth would cause paging. Instead, assuming object allocation fails and the heap cannot be compacted more, an OutOfMemoryError will be thrown. If -Xmx is set, the heap can grow up to the -Xmx value, but BEA JRockit will try full compaction before allowing the heap to grow to as size that causes paging.

For more information on heap sizing, please refer to Setting the Heap Size in Tuning the BEA JRockit 1.4.2 JVM.

Headless Management Console

This version of BEA JRockit allows you to view the Management Console, its notification subsystem, and the user actions without using a GUI. This function is refered to running the console in a "headless" mode and can greatly reduce the amount of system overhead required to run BEA JRockit.

For more information on this feature, please refer to Starting and Running the Console in the Headless Mode in Using BEA JRockit.

New JRE Packaging

The Java Runtime Environment, which is comprised of the BEA JRockit JVM and the components described in Standard JRE Features, has been repackaged so that it can now be installed separately from the SDK by using the JRE installer program shipped with this product. In previous versions of BEA JRockit, installing just the JRE required manipulating files within the various directory structures and posed a risk of error. The new installation instructions can be found in Installing the BEA JRockit 1.4.2 JRE.

Support for Browser Plugin on IA32 Machines

The Java Plugin extends the functionality of a web browser, allowing applets or Java Beans to be run under BEA JRockit JRE rather than the Java runtime environment that comes with the web browser. The Java Plugin is part of the BEA JRockit JRE and is installed when the JRE is installed on a computer. It works with both Netscape and Internet Explorer. This feature is available only on IA32 implementations of BEA JRockit.

For information on installing and using the Java plug-in, please refer to Using the Java Plugin.

Java.* Source Files and Demos Available

On edocs you can now find Java demos and sources for BEA JRockit 1.4.2.

Normally, these files are only available from Sun, but they can now be downloaded directly from:

http://download.oracle.com/docs/cd/E13188_01/jrockit/docs142/demo_src.html

You can download the source and demo files as .zip files and install them wherever you determine appropriate.

Java Web Start

This version of BEA JRockit includes an implementation of Java Web Start, a tool that allows you to start Java applications with a single click in your browser. With Web Start, you can download and launch applications directly from the browser and avoid complex and time-consuming installation procedures. Any Java application can be started by using Web Start.

Please refer to Using Web Start with BEA JRockit.

GC Support for Profiling Interface

The JVM Profiling Interface (JVMPI) is now supported on all garbage collectors. For more information on JVMPI, please refer to Profiling and Debugging with BEA JRockit 1.4.2.

man Pages Available for Linux Tools

For more information on the Linux man pages, please refer to Using the Linux man Pages.

 


Non-standard Features for 1.4.2_05

This section describes new, non-standard BEA JRockit features. Since these features are non-standard, they are provided "as-is" and are subject to change at any time. The feature described in this section is:

BEA JRockit Memory Leak Detector

The BEA JRockit Memory Leak Detector is a tool that detects memory leaks within Java applications running on BEA JRockit. A memory leak means application code holding on to memory which is not actually used by the application any more. The BEA JRockit Memory Leak Detector is a real-time profiling tool that gives information about what type of objects are allocated, how many, of what size and how they relate to each other.

For more information about the Memory Leak Detector, please refer to Using the BEA JRockit Memory Leak Detector.

Note: This product is provided "as-is," without any expressed or implied warranties or support by BEA Systems, Inc. This product, which may or may not become an officially supported product from BEA Systems, may contain errors and/or inaccuracies. Use of this product is left solely upon the discretion of the user without any endorsement from BEA Systems. The Memory Leak Detector functionality may or may not be available in future BEA JRockit versions. Questions and problems may be reported via online BEA JRockit newsgroups at http://newsgroups.bea.com.

 


Non-standard Features for 1.4.2_04

This section describes new, non-standard BEA JRockit features. Since these features are non-standard, they are provided "as-is" and are subject to change at any time. The features described in this section are:

Setting a Dynamic Garbage Collector with -Xgcprio

This version of BEA JRockit is released with a unified garbage collector that allows you to select a dynamic garbage collector based solely upon one of two priorities: memory throughput or duration of pause time caused by collection. The unified garbage collector is dynamic in that, as it runs, it uses predefined heuristics to determine which collection algorithm to use and changing that algorithm as the individual case might warrant. You do not need to specify the actual algorithm to run this garbage collector.

For more information on the unified garbage collector, please refer to Running the Dynamic Garbage Collector in Using BEA JRockit Memory System.

Manually Configuring the Garbage Collector

Three fixed garbage collectors originally available in earlier versions of BEA JRockit SDK are still available if you want to manually configure the garbage collector or override the default garbage collection settings available with the -server or -client flags.

The available garbage collectors are:

These options are useful if you think they meet your needs better than the unified collector or the default collectors. Additionally, if you want to continue to use scripts written for the earlier versions of BEA JRockit that implement these collectors, those scripts will continue to work without requiring any modification.

Note: The generational copy garbage collector, provided with BEA JRockit 8.1 SDK, is not provided with BEA JRockit 1.4.2 SDK.

JRockit Runtime Analyzer

The BEA JRockit Runtime Analyzer (JRA) is an internal experimental tool used by the BEA JRockit development team to analyze runtime performance of BEA JRockit and Java applications running on BEA JRockit. The tool provides a wealth of information on internals in BEA JRockit that are interesting to the development team. Some of these metrics are interesting to Java developers using BEA JRockit as their runtime as well.

Warning: JRA is provided "as-is," without any expressed or implied warranties or support by BEA Systems, Inc. This product might contain errors and/or inaccuracies. Its use is left solely upon the discretion of the user without any endorsement from BEA Systems.

Note: JRA supports only J2SE version 1.4 and higher.

New Features for JRA for 1.4.2_04

New features have been added expressly for the version of JRA available with BEA JRockit 1.4.2_04. They are not available with the version of JRA available with BEA JRockit 1.4.2_03.

These features are:

Note: If you are currently using the JRA tool included with BEA JRockit 1.4.2_03 and want access to these features, please download the latest version of the JRA at:

http://download.oracle.com/docs/cd/E13188_01/jrockit/docs142/JRA.zip

New Command-line Start-up Options

You can now start a JRA recording by using the command -XXjra and any of the following parameters:

delay

Amount of time, in seconds, to wait before recording starts.

recordingtime

Duration, in seconds, for the recording.

filename

The name of recording file.

sampletime

The time, in milliseconds, between samples.

nativesample

Displays method samples in native code; that is, you will see the names of functions written in C-code

For example:

-XXjra:delay=10,recordingtime=100,filename=jrarecording2.xml,sampletime=10000

Lock Profiling Information

You can now see comprehensive information about lock activity for the application JRA is monitoring on the Lock Profiling tab. A lock profile can only be generated when the -Djrockit.lockprofiling command is issued at the command line. For more information, please refer to Lock Profiling Tab.

New Usability Features

The following usability improvements have been made to the version of the JRA available with BEA JRockit 1.4.2_04:

For More Information

For more information on JRA, please refer to Using the BEA JRockit Runtime Analyzer

Code Caching

Code caching—or code persistence—is the process of storing generated code to disk for retrieval when that code is required later. Since cached code is already generated, the time that code generation would require on subsequent startups is no longer an issue and—usually—execution time is reduced. For more information on Code Caching, please refer to Code Caching with BEA JRockit.

Note: This feature is available only in BEA JRockit 1.4.2_04.

 

Skip navigation bar  Back to Top Previous Next