Content starts here

Oracle JRockit Frequently Asked Questions

This page answers some frequently asked questions about Oracle JRockit.

This page was last updated June, 2008.

General

Oracle JRockit Mission Control

Monitoring and Tuning

Features

Troubleshooting

Time Zone Updates

Further Information

General

What is a Java Virtual Machine?

The Java Virtual Machine Specification describes a JVM thusly:

The Java virtual machine is the cornerstone of the Java and Java 2 platforms. It is the component of the technology responsible for its hardware- and operating system- independence, the small size of its compiled code, and its ability to protect users from malicious programs.

A JVM is the program translating and running your Java application, from the Java bytecode located in .class files to the native language known to the specific operating system/processor you want your java program to run on. Each JVM thus comes in different flavors for each different os/processor combination. To see which operating system/processors supported by the JRockit JVM, please refer to Supported Configurations

What is the difference between the Sun JVM and JRockit JVM?

The most well know JVM is the implementation from Sun. The Sun JVM is called HotSpot. The Sun JVM is shipped in the Java Developer's Kit (JDK) and Java Runtime Environment (JRE) from Sun.

The JRockit JVM from is optimized for reliability and performance for server side applications. To achieve this, JRockit JVM uses technologies such as code generation, hot spot detection, code optimization, advanced garbage collection algorithms and tight operating system integration.

Should I write my applications differently for the JRockit JVM?

No! You should not write your applications in any other way for JRockit JVM than you should for any other JVM. You should, however, design and implement your applications well in order for them to run well on JRockit JVM. See Developing Java Applications for some recommended coding practices.

Are the JRockit JVM class libraries compatible with Sun?

Yes, the JRockit JVM class library is completely compatible with the Sun class library.

On which platforms can I run the JRockit JVM ?

In the Supported Platforms document, you find a complete list of all platforms that the JRockit JVM supports.

Does the JRockit JVMsupport Java Web Start and Java Plug-in?

No. This functionality was removed in version R26.2 of the JRockit JVM.

How do I migrate from the Sun JVM to the JRockit JVM?

See Migrating Applications to the JRockit JVM in the Diagnostics Guide for information on migrating to the JRockit JVM.

I am not sure that I am running on the JRockit JVM? How do I verify this and make sure that I run the JRockit JVM by default?

Run the command

java -version

to verify your Java version. If the Java version is not the JRockit JVM, verify that the JRockit JVM is in the path before any other JVMs. Note that on Windows some JVMs are installed in the windows system folder (C:\Windows\System32), which means that the JRockit JVM must be in the path before the system folder; for example:

set PATH="D:\Program Files\bea\jrockit90_150_04\bin";%PATH%

If I'm using BEA JRockit 7.0, which is built on J2SE 1.3.1, what should I do now that this J2SE version is no longer supported?

We highly recommend that you upgrade your JRockit JVM version to either the latest version of JRockit JDK 1.4.2 or 5.0. Not only are these versions built on well-supported J2SE's, but both JRockit versions exhibit markedly superior performance and offer more robust features. When you replace your existing JVM with either of these versions-and assuming you make no or minimal changes to your application-the JRockit JVM will deliver:

  • Improved performance
  • Improved startup time
  • Much improved -Xdebug mode

For instructions on upgrading to one of the current JRockit JVM versions, please refer to the Upgrade Guide.

Where do I find published benchmark figures?

On the site from Standard Performance Evaluation Corporation you can find recent and relevant benchmarking figures.

Oracle JRockit Mission Control

I get the error message: Could not create the Java virtual machine. What do I need to do?

Please check the spelling of the startup options that you have used. If you still cannot start the JVM, look in the Reference Manual for the available startup options.

I get the error message: Error: Password file not found when using -Xmanagement. What do I need to do?

The management agent requires that you either explicitly disable security or that you configure and enable security. Please see the documentation for -Xmanagement for details.

How do I create a JRA-recording?

A JRockit Runtime Analyzer (JRA) recording is a way for you to study the performance of the JRockit JVM for a set time period. For information on how to use the tool, see Using the JRockit Runtime Analyzer.

Note! As mentioned in How can I monitor my running application?, the JRA is now part of Oracle JRockit Mission Control and requires a special license. The documentation for these tools are included as online help To acquire the proper license, please go to: http://dev2dev.bea.com/jrockit/tools.html

Monitoring and Tuning

How can I monitor my running application using Oracle JRockit Mission Control?

Oracle JRockit Mission Control is comprised of the following features:

  • Management Console: this tool is used to monitor and manage multiple (or single) JRockit JVM instances. It captures and presents live data about memory, CPU usage, and other runtime metrics. For more information, see Using the Management Console.
  • JRockit Runtime Analyzer: this tool is an on-demand "flight recorder" that produces detailed recordings about the JVM and the application it is running. The recorded profile can later be analyzed off line, using the JRA tool. For more information, see Using the JRockit Runtime Analyzer.
  • Memory Leak Detector: use this tool to find the cause for memory leaks in a Java application. The JRockit Memory Leak Detector's trend analyzer discovers slow leaks, it shows detailed heap statistics (including referring types and instances to leaking objects), allocation sites, and it provides a quick drill down to the cause of the memory leak. For more information, see Using the Memory Leak Detector.

For general information on Oracle JRockit Mission Control, please refer to the Introduction to Oracle JRockit Mission Control.

Also, JRockit JDK 5.0 and later versions fully support the Java Management standards. This means that you can use any 3rd party management tool that uses JMX to monitor and manage the JRockit JVM process.

Which command line options should I use to tune the performance of the JRockit JVM?

You can find information on the basics on tuning the JRockit JVM in First Steps of Tuning the JRockit JVM in the Oracle JRockit JVM Diagnostics Guide.

Which garbage collection algorithm should I use for my application?

In most cases you do not need to set the garbage collector at all, it is already set to the default dynamic (-Xgcprio:throughput) garbage collector; however, for some applications, you could have specific needs, such as a need for short pause times. In that case the applications can benefit if you set the garbage collector specifically to suit those needs. See Tuning the Memory Management System in the Oracle JRockit JVM Diagnostics Guide.

Features

Does the JRockit JVM support PAE on Windows?

Physical Address Extension (PAE) provides the possibility to map physical memory into your process virtual memory address space. At any given time, you can still have just 2 GB mapped (3 GB with the /3GB option); that is, you have to re-use a portion of the virtual address space to map different portions of the physical address space. Therefore you cannot simply address more memory with regular pointers. This does not work well with a normal Java heap, which uses 32-bit pointers to reference objects and needs the entire heap in the virtual address space at all times.

PAE works well with applications that can jointly control mapping and memory access. At this point this is not well suited for Java. However a native database driver might use PAE to cache data. You should discuss with the various database vendors how to make this happen (if it is not available already). You might even create a custom cache by rolling your own “DB access layer” on top of a native database API using JNI.

Other ways of using your plentiful physical memory includes using several Java processes (each Windows process can get 2 GB physical memory to use for its private address space).

If you a need a larger Java heap, you need to use a 64-bit implementation of the JRockit JVM; that is, either the Itanium version or the native Windows x64 version for 64-bit Xeon/AMD64.

Does the JRockit JVM support thread priorities?

Yes, the JRockit JVM supports thread priorities on Windows (both IA32 and Itanium); It is not supported on Linux or Solaris.

If you are running either IA32 or Itanium Windows, you can configure the JVM to stop ignoring priority change requests by passing the flag -XXusethreadpriorities. Despite being valid on all platforms, this flag is only meaningful on Windows.

Priority change requests are ignored by default because, if they are improperly applied, applications will behave worse than before the change. If you set priority too high for a thread, it will consume too many resources, severely impacting performance. On the other hand, if you set it too low, priority inversion can result. Priority inversion means that high priority threads never get to run because they are waiting for a lock held by a low priority thread, which itself never gets the chance to release the lock because the high priority threads get all the CPU time. Because of this, setting and using priorities should be attempted only by expert programmers.

Troubleshooting

I cannot get my favorite Java application to run on the JRockit JVM. What am I doing wrong?

Many problems with running applications on the JRockit JVM is due to erroneous environment variables or non-standard startup options. Start by ensuring that your environment variables are set up correctly. Make sure that you have set your JAVA_HOME environment variable correctly, i.e. set to the directory where the JRockit JVM has been installed, and that %JAVA_HOME%\bin is available in your PATH environment variable before any other directory where any version of java.exe may exist. When running applications as Windows services it is crucial that you set these environment variables system wide. To do this:

  1. Open the Start menu and select Settings>Control Panel>System
  2. Select the Advanced tab
  3. Click Environment Variables

To set system wide environment variables you must edit in the lower part of this dialog box, labeled System variables.

Applications are often started via scripts. Make sure that none of the startup scripts includes non-standard startup options for java. See the Reference Manual for complete documentation of standard and non-standard options.

The JRockit JVM has crashed unexpectedly. What can I do?

Read about how to diagnose and troubleshoot crashes in Troubleshooting JRockit JVM Crashes.

The JRockit JVM has frozen and is unresponsive. What can I do?

Read about how to diagnose and troubleshoot the JRockit JVM in case it freezes in The Oracle JRockit JVM is Freezing.

The JRockit JVM starts slowly. What can I do?

Java programs are compiled into byte code by a Java compiler. Many JVMs, including the Sun JVM, interprets this byte code each time it is executed. The JRockit JVM, however, uses code generation technology to generate native machine code from the byte code. This is sometimes called Just-In-Time (JIT) compilation. The code generation step imposes an initial time penalty before execution. Normally, the subsequent execution of the code is faster than interpreting the byte code. The JRockit JVM is optimized for server applications that normally run for long periods of times. The initial time penalty is normally negligible in comparison to the performance gains of code generation over time.

Read about how to diagnose and troubleshoot a slow start-up in The Oracle JRockit JVM Starts Slowly.

The throughput of my Java application is low. What can I do?

Read about how to diagnose and troubleshoot poor performance (low throughput) by tuning the JVM in Tuning For Better Application Throughput .

The JRockit JVM is running with high response times. What can I do?

Read about how to diagnose and troubleshoot long response times (pausetimes) by tuning the JVM in Tuning For Faster Individual Transactions.

The JRockit JVM's performance degrades over time. What can I do?

Read about how to troubleshoot performance degradation in The Oracle JRockit JVM's Performance is Degrading Over Time.

Why does my application have randomly appearing bugs when running on the JRockit JVM that it doesn't have when running on the Sun JVM?

You may be experiencing synchronization bugs in your application. It is not uncommon that such bugs are revealed when switching JVMs. The JVM specification and the Java language specification leaves plenty of room for optimization that may cause unsynchronized access to shared data, to cause different behavior on different JVMs.

For more information see: http://java.sun.com/docs/books/jls/second_edition/html/memory.doc.html and http://java.sun.com/docs/books/vmspec/2nd-edition/html/Threads.doc.html

Why is the JRockit JVM throwing IllegalAccessError, ClassFormatError, IncompatibleClassChangeError or other LinkageError exceptions when the Sun JVM is not?

Verification ensures that the binary representation of a class or interface is structurally correct. For example, it checks that every instruction has a valid operation code; that every branch instruction branches to the start of some other instruction, rather than into the middle of an instruction; that every method is provided with a structurally correct signature; and that every instruction obeys the type discipline of the Java programming language.

If an error occurs during verification, then a linkage error will be thrown at the point in the program that caused the class to be verified; for example:

Using JTidy throws IllegalAccessError

In an early version of JTidy from Apache Software Foundation, the compiler had incorrectly inlined a reference to a private variable belonging to an outer class. This caused an exception to be thrown since the JRockit JVM does stricter verification than the Sun JVM is. The old Tidy.jar should be replaced with the new and correctly compiled version.

Why is the JRockit JVM slower when Oracle WebLogic Server is running in development mode?

When WebLogic Server is started in development mode, the JRockit JVM is by default started with the -Xdebug option. This makes the JRockit JVM run with some overhead.

Sometimes, when running the JRockit JVM, I encounter a NotAvailableException when the console tries to connect to JRockit or if the program itself tries to access the CPU load counters.

Occasionally, the process counter does not initialize. This happens only on Windows installations where either the security settings are such that the Performance Data Helper (PDH; a Windows API that reads performance metrics from the operating system) process counter can't be read or where, for reasons unknown, the PDH process counter is simply turned off. This will deny you the rights to look at the process counter and throw the error. You will receive this message:

[JRockit] WARNING: Could not initialize the virtualbytes counter, some functionality in jrockit.management.Memory will not be available. Message was: failed to create counter query. String was: (null)\Virtual Bytes

[JRockit] WARNING: Could not initialize the JVM process load counter, CPU load generated by the JVM will not be available. Message was: failed to create counter query. String was: (null)\% Processor Time

Why the process counter is turned off is unknown; however, should you encounter this situation, you can turn it on again by following the instructions at this location: http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/exctrlst-o.asp. If that doesn't work, check your security settings and then make sure the performance counters can be read using the Windows perfmon tool, running as the same user that the JVM process is running as.

Why am I getting too many open files error when running Runtime.exec?

The use of Runtime.exec() commits native resources in an unintuitive way that may lead to an IOException.

The reason for this error message is that Runtime.exec() uses file handles for its stdin, stdout, and stderr streams. These streams are normally handled through the object's finalizer. However, if Runtime.exec() is called very frequently then the JRockit JVM will typically not trigger a garbage collection before it runs out of native file handles. The garbage collection is needed for the JVM to find out that the process objects and stream handles are no longer reachable and have become candidates for finalization. This problem is more likely to occur when garbage collections are infrequent, such as when using a single-spaced garbage collector with a large heap, which in turn is the default garbage collection strategy for the JRockit JVM -Xgcprio:throughput.

Workaround: The best workaround when working with native resources is always to release them explicitly when they are no longer needed instead of depend on that finalizers are run--the only contract with finalizers are that they will be run at some point in time after the object has become unreachable. You can close a process named proc manually by doing something like this:

proc.waitFor(); // waits for the process to terminate - returns immediately if the sub process has already terminated
proc.getInputStream.close(); // close each of the streams in turn - internal order does not matter
proc.getOutputStream.close();
proc.getErrorStream.close();

This can of course be done asynchronously in a separate thread if needed. Be aware that this also applies to all normal stream objects backed by a native file handle (for example FileInputStream) and other objects like Sockets.

A less efficient workaround is to try to tweak the garbage collection strategy to run generational and/or run with a smaller object heap. In that case it is question of luck if the release of native resources keeps up with the application or not.

Time Zone Updates

I need to update time zone information to accommodate daylight saving time changes. What should I do?

Read about how to update time zone information in Oracle JRockit Time Zone Updater.

Is the Oracle JRockit Time Zone Updater the same as the Sun TZUpdater?

No, not exactly, but very close.

The Sun TZUpdater caused certain JRockit versions on Windows to crash when clearing time zone data caches. Therefore, the Oracle version does not clear those caches. As a consequence, the Oracle version of the tool cannot perform validation tests for JRE upgrades right after the update is made since the caches might contain old time zone data. The workaround is to run the TZUpdater with the -t flag after you have upgraded a JRE to validate that the time zone data is updated.

See Oracle JRockit Time Zone Updater for more information on how to use the tool.

There is a bug in Java 1.4.2_12 where EST (Eastern Standard Time) does not get affected by DST (Daylight Saving Time), will the TZUpdater fix this?

No, not by default. The EST issue is not considered a bug. The use of three letter time zone IDs is deprecated since Java 1.4. Since tzdata2005r (in the Olsen time zone database), daylight saving time does not apply to EST. Sun has chosen compatibility with Olsen tzdata (as well as Solaris and Linux) over compatibility with Java 1.1.x. The recommended solution is to use the Olsen time zone IDs - "America/New_York" instead of "EST". However, you can run tzupdater with the -bc argument to use the old, backwards compatible meaning of EST (of course, the new daylight saving time rules will still be included).

This has however been fixed in the following versions of the JRockit JVM:

  • R27.3.1 142_14
  • R27.4.0 150_12
  • R27.3.1 1.6.0_01

How do I know which version of the TZUpdater I'm using?

Use the command tzinfo to see which version of TZUpdater you're using. Enter the command from your Oracle JRockit version directory's bin/ directory. The system will respond with complete version information; for example:

Enter:
\jrockits\R27.3.0_R27.3.0-45_1.5.0\bin\tzinfo
The system responds:
java version "1.5.0_10" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03) Oracle JRockit(R) (build R27.3.0-45-79733-1.5.0_10-20070330-1521-windows-ia32,
compiled mode)
Time zone data version: tzdata2006k

Further Information

Where can I find a forum where I can discuss my experiences with Oracle JRockit?

Oracle provides a developer newsgroup on http://forums.bea.com/bea/forum.jspa?forumID=2009.

How do I submit a problem report on the JRockit JVM to Oracle Support?

See Submitting Problems to Oracle Support for information on how to submit a problem report.