While parts of this book, mainly the first part, contain generic information on the inner workings of all adaptive runtimes, the examples and in-depth information still assume that the JRockit JVM is used. This chapter briefly explains how to obtain the JRockit JVM and covers porting issues that may arise while deploying your Java application on JRockit.
In this chapter, you will learn:
How to obtain JRockit
The platforms supported by JRockit
How to migrate to JRockit
About the command-line options to JRockit
How to interpret JRockit version numbers
Where to get help if you run into trouble
To get the most out of this book, the latest version of the JRockit JVM is required. For JRockit versions prior to R27.5, a license key was required to access some of the more advanced features in JRockit. As part of the Oracle acquisition of BEA Systems, the license system was removed and it is now possible to access all features in JRockit without any license key at all. This makes it much easier to evaluate JRockit and to use JRockit in development. To use JRockit in production, a license must still be purchased. For Oracle customers, this is rarely an issue, as JRockit is included with most application suites, for example, any suite that includes WebLogic Server will also include JRockit.
At the time of writing, the easiest way to get a JRockit JVM is to download and install JRockit Mission Control—the diagnostics and profiling tools suite for JRockit. The folder layout of the Mission Control distribution is nearly identical to that of any JDK and can readily be used as a JDK. The authors would very much like to be able to provide a self-contained JVM-only JDK for JRockit, but this is currently beyond our control. We anticipate this will change in the near future.
Before JRockit Mission Control is downloaded, ensure that a supported platform is used. The server part of Mission Control is supported on all platforms for which JRockit is supported.
Following is the platform matrix for JRockit Mission Control 3.1.x:
|
Platform |
Java 1.4.2 |
Java 5.0 |
Java 6 |
|---|---|---|---|
|
Linux x86 |
X |
X |
X |
|
Linux x86-64 |
N/A |
X |
X |
|
Linux Itanium |
X (server only) |
X (server only) |
N/A |
|
Solaris SPARC (64-bit) |
X (server only) |
X (server only) |
X (server only) |
|
Windows x86 |
X |
X |
X |
|
Windows x86-64 |
N/A |
X (server only) |
X (server only) |
|
Windows Itanium |
X (server only) |
X (server only) |
N/A |
Following is the platform matrix for JRockit Mission Control 4.0.0:
|
Platform |
Java 5.0 |
Java 6 |
|---|---|---|
|
Linux x86 |
X |
X |
|
Linux x86-64 |
X |
X |
|
Solaris SPARC (64-bit) |
X (server only) |
X (server only) |
|
Windows x86 |
X |
X |
|
Windows x86-64 |
X |
X |
Note that the JRockit Mission Control client is not (yet) supported on Solaris, but that 64-bit Windows support has been added in 4.0.0.
Note
When running JRockit Mission Control on Windows, ensure that the system's temporary directory is on a file system that supports per-user file access rights. In other words, make sure it is not on a FAT formatted disk. On a FAT formatted disk, essential features such as automatic discovery of local JVMs will be disabled.
The easiest way to get to the JRockit home page is to go to your favorite search engine and type in "download JRockit". You should end up on a page on the Oracle Technology Network from which the JVM and the Mission Control suite can be downloaded. The installation process varies between platforms, but should be rather self explanatory.
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.
The way JRockit is versioned can be a little confusing. There are at least three version numbers of interest for each JRockit release:
The JRockit JVM version.
The JDK version.
The Mission Control version.
One way to obtain the version number of the JVM is to run java –version from the command prompt. This would typically result in something like the following lines being printed to the console:
java version "1.6.0_14" Java(TM) SE Runtime Environment (build 1.6.0_14-b08) Oracle JRockit(R) (build R28.0.0-582-123273-1.6.0_14-20091029-2121-windows-ia32, compiled mode)
The first version number is the JDK version being bundled with the JVM. This number is in sync with the standard JDK versions, for the JDK shipped with HotSpot. From the example, we can gather that Java 1.6 is supported and that it is bundled with the JDK classes from update 14-b08. If you, for example, are looking to see what JDK class-level security fixes are included in a certain release, this would be the version number to check.
The JRockit version is the version number starting with an 'R'. In the above example this would be R28.0.0. Each version of the JRockit JVM is built for several different JDKs. The R27.6.5, for instance, exists in versions for Java 1.4, 1.5 (5.0) and 1.6 (6.0). With the R28 version of JRockit, the support for Java 1.4 was phased out.
The number following the version number is the build number, and the number after that is the change number from the versioning system. In the example, the build number was 582 and the change number 123273. The two numbers after the change number are the date (in compact ISO 8601 format) and time (CET) the build was made. After that comes the operating system and CPU architecture that the JVM was built for.
The version number for JRockit Mission Control can be gathered by executing jrmc -version or jrmc -version | more from the command line.
Note
On Windows, the JRockit Mission Control launcher (jrmc) is based on the javaw launcher to avoid opening a console window. Console output will not show unless explicitly redirected, for example to more.
The output should look like this:
Oracle JRockit(R) Mission Control(TM) 4.0 (for JRockit R28.0.0) java.vm.version = R28.0.0-582-123273-1.6.0_14-20091029-2121-windows-ia32 build = R28.0.0-582 chno = 123217 jrmc.fullversion = 4.0.0 jrmc.version = 4.0 jrockit.version = R28.0.0 year = 2009
The first line tells us what version of Mission Control this is and what version of JRockit it was created for. The java.vm.version line tells us what JVM Mission Control is actually running on. If Mission Control has been launched too "creatively", for example by directly invoking its main class, there may be differences between the JVM information in the two lines. If this is the case, some functionality in JRockit Mission Control, such as automatic local JVM discovery, may be disabled.
There are plenty of helpful resources on JRockit and JRockit Mission Control available on the Oracle Technology Network, such as blogs, articles, and forums. JRockit developers and support staff are continuously monitoring the forums, so if an answer to a particular question cannot be found in the forums already, it is usually answered within a few days. Some questions are asked more frequently than others and have been made into "stickies"—forum posts that will stay at the top of the topic listings. There is, for example, a "sticky" available on how to acquire license files for older versions of JRockit.
Note
The JRockit Forum can, at the time of writing, be found here:
http://forums.oracle.com/forums/forum.jspa?forumID=561
Here are the locations of some popular JRockit blogs:
This chapter provided a short guide for getting started with the JRockit JVM and for migrating existing applications to the JRockit JVM. We covered installing JRockit and provided insights into common pitfalls when migrating a Java application from one JVM to another.
The different categories of command-line flags that JRockit supports were explained, and we showed examples of how to find the version numbers for the different components of the JRockit JDK.
Finally, we provided pointers to additional help.
