Skip navigation.
Downloads | Product Documentation | Support

BEA JRockit JDK Frequently Asked Questions

This page answers some frequently asked questions about BEA JRockit.

- On which platforms can I run BEA JRockit?
- Where do I find published benchmark figures?
- How can I monitor my running application?
- I get the error message:`Could not create the Java virtual machine.` What do I need to do?
- How do I perform a JRA-recording?
- Which garbage collection algorithm should I use for my application?
- Are the BEA JRockit class libraries compatible with Sun?
- Does dynamic optimization conflict with my application?
- Does BEA JRockit support PAE?
- Does BEA JRockit support thread priorities?
- Where can I find a forum where I can discuss my experiences with BEA JRockit?

On which platforms can I run BEA JRockit?

On the Supported Platforms page, you find a complete list of all platforms JRockit supports.

Where do I find published benchmark figures?

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

How can I monitor my running application?

BEA JRockit is delivered with a built-in monitoring tool called BEA JRockit Management Console. For information on how to use the Management Console, see Using the BEA JRockit Management Console.

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 Command Line Options document for the available startup options. You can also look in the document Tuning BEA JRockit JVM for more information on how to best tune your JVM.

How do I perform a JRA-recording?

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

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 Using the BEA JRockit Memory Management System.

Are the BEA JRockit class libraries compatible with Sun?

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

Does dynamic optimization conflict with my application?

The dynamic optimization is done in parallel with the rest of the code generation. This means that there really is no conflict with the running of your application. Most code pieces are not optimized, since that takes too many resources from the code generation.

Does BEA JRockit support PAE?

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 BEA JRockit; that is, the Itanium versions for Windows 2003 or Linux.

Does BEA JRockit support thread priorities?

On BEA JRockit 5.0, the only platforms we support that have thread priorities are Windows (both IA32 and Itanium); It is not supported on Linux.

Despite applying only to Windows platforms, Sun’s default behavior dictates that BEA JRockit ignore all thread priority change requests from Java on all platforms. 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`; however, 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.

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

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