Throughout this book, we will refer to the directory where the JRockit JVM is installed as JROCKIT_HOME. It might simplify things to make JROCKIT_HOME a system variable pointing to that particular path. After the installation has completed, it is a good idea to put the JROCKIT_HOME/bin directory on the path and to update the scripts for any Java applications that should be migrated to JRockit. Setting the JAVA_HOME environment variable to JROCKIT_HOME is also recommended. In most respects JRockit is a direct drop in replacement for other JVMs, but some startup arguments, for example arguments that control specific garbage collection behavior, typically differ between JVMs from different vendors. Common arguments, however, such as arguments for setting a maximum heap size, tend to be standardized between JVMs.
Note
For more information about specific migration details, see the Migrating Applications to the Oracle JRockit JDK Chapter in the online documentation for JRockit.
There are three main types of command-line options to JRockit—system properties, standardized options (-X flags), and non-standard ones (-XX flags).
Startup arguments to a JVM come in many different flavors. Arguments starting with –D are interpreted as a directive to set a system property. Such system properties can provide configuration settings for various parts of the Java class libraries, for example RMI. JRockit Mission Control provides debugging information if started with –Dcom.jrockit.mc.debug=true. In JRockit versions post R28, the use of system properties to provide parameters to the JVM has been mostly deprecated. Instead, most options to the JVM are provided through non-standard options and the new HotSpot style VM flags.
Configuration settings for the JVM typically start with -X for settings that are commonly supported across vendors. For example, the option for setting the maximum heap size, -Xmx, is the same on most JVMs, JRockit included. There are a few exceptions here. The JRockit flag –Xverbose provides logging with optional sub modules. The similar (but more limited) flag in HotSpot is called just –verbose.
Vendor-specific configuration options are usually prefixed with -XX. These options should be treated as potentially unsupported and subject to change without notice. If any JVM setup depends on -XX-prefixed options, those flags should be removed or ported before an application is started on a JVM from a different vendor.
Once the JVM options have been determined, the user application can be started. Typically, moving an existing application to JRockit leads to an increase in runtime performance and a slight increase in memory consumption.
The JVM documentation should always be consulted to determine if non-standard command-line options have the same semantics between different JVMs and JVM versions.
In JRockit versions post R28, there is also a subset of the non-standard options called VM flags. The VM flags use the -XX:<flag>=<value> syntax. These flags can also be read and, depending on the particular flag, written using the command-line utility JRCMD after the JVM has been started. For more information on JRCMD, see Chapter 11.
Sometimes there is a change of runtime behavior when moving from one JVM to another. Usually it boils down to different JVMs interpreting the Java Language Specification or Java Virtual Machine Specification differently, but correctly. In several places there is some leeway in the specification that allows different vendors to implement the functionality in a way that best suits the vendor's architecture. If an application relies too much on a particular implementation of the specification, the application will almost certainly fail when switching to another implementation.
For example, during the milestone testing for an older version of Eclipse, some of the tests started failing when running on JRockit. This was due to the tests having inter-test dependencies, and this particular set of tests were relying on the test harness running the tests in a particular order. The JRockit implementation of the reflective listing of methods (Class#getDeclaredMethods) did not return the methods in the same order as other JVMs, which according to the specification is fine. It was later decided by the Eclipse development team that relying on a particular method ordering was a bug, and the tests were consequently corrected.
If an application has not been written to the specification, but rather to the behavior of the JVM from a certain vendor, it can fail. It can even fail when running with a more recent version of the JVM from the same vendor. When in doubt, consult the Java Language Specification and the documentation for the JDK.
Differences in performance may also be an issue when switching JVMs for an application. Latent bugs that weren't an issue with one JVM may well be an issue with another, if for example, performance differences cause events to trigger earlier or later than before. These things tend to generate support issues but are rarely the fault of the JVM.
For example, a customer reported that JRockit crashed after only a day. Investigation concluded that the application also crashed with a JVM from another vendor, but it took a few more days for the application to crash. It was found that the crashing program ran faster in JRockit, and that the problem; a memory leak, simply came to light much more quickly.
Naturally, any JVM, JRockit included, can have bugs. In order to brand itself "Java", a Java Virtual Machine implementation has to pass an extensive test suite—the Java Compatibility Kit (JCK).
JRockit is continuously subjected to a battery of tests using a distributed test system. Large test suites, of which the JCK is one component, are run to ensure that JRockit can be released as a stable, Java compatible, and certified JVM. Large test suites from various high profile products, such as Eclipse and WebLogic Server, as well as specially designed stress tests, are run on all supported platforms before a release can take place. Continuous testing against performance regressions is also done as a fundamental part of our QA infrastructure. Even so, bugs do happen. If JRockit does crash, it should always be reported to Oracle support engineers.