The dynamic optimization is done in parallell 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 IA-64 versions for Windows 2003 or Linux.