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.