This section provides some tips on collecting performance numbers with Jikes RVM.
Which boot image should I use?
To make a long story short the best performing configuration of Jikes RVM will almost always be
production. Unless you really know what you are doing, don't use any other configuration to do a performance evaluation of Jikes RVM.
Any boot image you use for performance evaluation must have the following characteristics for the results to be meaningful:
- config.assertions=none. Unless this is set, the runtime system and optimizing compiler will perform fairly extensive assertion checking. This introduces significant runtime overhead. By convention, a configuration with the Fast prefix disables assertion checking.
- config.bootimage.compiler=opt. Unless this is set, the boot image will be compiled with the baseline compiler and virtual machine performance will be abysmal. Jikes RVM has been designed under the assumption that aggressive inlining and optimization will be applied to the VM source code.
- Any configuration that performs opt compilation at runtime (config.include.aos=1 should be built with config.include.all-classes=1). This includes the optimizing compiler and associated support classes in the boot image where they can be optimized by the boot image compiler. By convention, configurations that include the opt compiler in the boot image have the Full or Fast prefix. Configurations where config.include.all-classes is not set to 1 that use the optimizing compiler will dynamically load it (which will force it to be baseline compiled).
What command-line arguments should I use?
For best performance we recommend the following:
-processors all: By default, Jikes™ RVM uses only one processor. Setting this option tells the runtime system to utilize all available processors.
- Set the heap size generously. We typically set the heap size to at least half the physical memory on a machine.
- Use a dedicated machine with no other users. The Jikes RVM thread and synchronization implementation do not play well with others.
The compiler-replay methodology is deterministic and eliminates memory allocation and mutator variations due to non-deterministic application of the adaptive compiler. We need this latter methodology because the non-determinism of the adaptive compilation system makes it a difficult platform for detailed performance studies. For example, we cannot determine if a variation is due to the system change being studied or just a different application of the adaptive compiler. The information we record and use are hot methods and blocks information. We also record dynamic call graph with calling frequency on each edge for inlining decisions.
Here is how to use it:
- Generate the profile information, using the following command line arguments:For edge profile:
- Use the profile you generated for compiler replay, using the following command line arguments: