BEA JRockit JDK Frequently Asked Questions
This page answers some frequently asked questions about BEA JRockit.
Could not create the Java virtual machine.What do I need to do?
On the Supported Platforms page, you find a complete list of all platforms JRockit supports.
On the site from Standard Performance Evaluation Corporation you can find recent and relevant benchmarking figures.
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.
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.
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.
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.
Yes, the BEA JRockit class library is completely compatible with the Sun class library.
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.
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.
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.
BEA provides a developer newsgroup on http://forums.bea.com/bea/forum.jspa?forumID=2009.