Migrating Applications to the Oracle JRockit JDK

This section describes how to migrate Java applications developed on another JDKs to the Oracle JRockit JDK to ensure optimal performance during runtime. This section contains information on the following subjects:

About Application Migration

Migrating an application to the JRockit JDK is a relatively simple process, requiring some minor environmental changes and following some simple coding guidelines. This section provides instructions and tips to successfully completing this simple process. It also describes some of the benefits and possible problems you might encounter during migration and it discusses some best J2SE coding practices for you to follow to ensure that your application runs successfully once it is running on the JRockit JDK.

Why Migrate?

The JRockit JDK is the default JDK shipped with Oracle WebLogic Server. Although there are other JDKs available on the market today that you can use to develop Java applications, Oracle recommends that you use JRockit JDK with your Oracle products.

Migration Restrictions

Migration is available for all platforms when Oracle WebLogic Server is supported with the JRockit JDK. For a list of supported platforms, please refer to:

Migration Support

Should you experience any problems or find any bugs while attempting to migrate an application to the JRockit JDK, please send us an e-mail at support@bea.com. We would appreciate if you could provide as much information as possible about the problem, for example:

Hardware
Operating system and its version
The program you are attempting to migrate
Stack dumps (if any)
A small code example that will reproduce the error
Copies of any *.dump and *.mdmp/core process memory dump files. On Windows they are stored as *.mdmp, on Linux and Solaris as core or core.*

Migration Procedures

This section describes basic environmental and implementation changes necessary to migrate to JRockit JDK from a third-party JDK, such as the Sun Microsystems JDK. It includes information on the following subjects:

Environment Changes

To migrate from a third-party JDK to the JRockit JDK, you need to make the following changes to the files.

Set the JAVA_HOME environmental variable in <WEBLOGIC_HOME>/common/commEnv.cmd (or .sh) to the appropriate path.
Set the JAVA_VENDOR environmental variable in <WEBLOGIC_HOME>/common/commEnv.cmd (or .sh) to BEA.
If you are using a start-up script, remove any Sun-specific (or other JVM provider) options from the start command line (like -XX:NewSize). If possible, replace them with Oracle JRockit JVM-specific options; for example, -Xns. Other flags that might need to be changed include MEM_ARGS and JAVA_VM.

(For more information on command-line options supported by the JRockit JVM, please refer to the Reference Manual.)

Change config.xml to point the default compiler setting(s) to the javac compiler in the JRockit JDK.

Other Tips

For information on other coding practices that will ensure a successful migration of your application to the JRockit JDK, please refer to Developing Java Applications .

Tuning the JRockit JVM for Your Application

Once you’ve migrated your application to the JRockit JDK, you might want to tune the JVM for optimal performance. For example, you might want to specify a different start-up heap size or set custom garbage collection parameters. You can find detailed information on tuning the JRockit JVM in the chapters of the section Profiling and Performance Tuning.

The non-standard options, that is, options preceded with -X, are critical tools for tuning a JVM at startup. These options change the behavior of the JRockit JVM to better suit the needs of different Java applications.

While all JVMs use non-standard options, the option names might not be the same from JVM to JVM; for example, while the JRockit JVM will accept the non-standard option -Xns to set the nursery in generational concurrent and generational parallel garbage collectors, Sun’s HotSpot JVM uses the non-standard option -XX:NewSize to set this value.

If you are migrating an application to the JRockit JDK, we recommend that you become familiar with the non-standard options available to you. For more information, please refer to the Reference Manual.

You should also be aware that, being non-standard, non-standard options are subject to change at any time.

Testing the Application

Always test your application on the JRockit JVM before putting it into production. If you develop your application on the Sun JVM (HotSpot), you must test your application on the JRockit JVM before you put it into production.

Why Test?

How to Test

Replicating Tools Supplied with the Sun JDK

The following J2SE tools, normally available with the Sun JDK, are not shipped with the JRockit JDK:

The JRockit JDK provides internal tools that are equivalent to or better than most of the Sun tools. Listing 5-1 lists the Sun tools and their JRockit JDK equivalents. Some of these tools require using the jrcmd feature. For more information, please refer to Running Diagnostic Commands

Table 5-1 JRockit JDK/Sun Tool Equivalents
Sun Tool	Shipped with JRockit JDK	JRockit JDK Equivalent
`jinfo`	No	`jrcmd <pid> print_properties` `jrcmd <pid> command_line`
`jhat`	No	JRockit Memory Leak Detector (see The JRockit Memory Leak Detector) and JRockit Runtime Analyzer (see The JRockit Runtime Analyzer).
`jmap`	No	JRockit Memory Leak Detector (see The JRockit Memory Leak Detector) `jrcmd <pid> print_object_summary` `jrcmd <pid> verbose_referents` `jrcmd <pid> heap_diagnostics`
`jsadebugd`	No	No equivalent tool
`jstack`	No	`jrcmd <pid> print_threads`
`jps`	Yes	`jrcmd`
`jstat`	Yes	No equivalent, `jstat` works with the JRockit JVM. The JRockit Runtime Analyzer (see The JRockit Runtime Analyzer) and the JRockit Management Console in Oracle JRockit Mission Control (see The JRockit Management Console) are however better tools for this purpose.
`jstatd`	Yes	No equivalent, `jstatd` works with the JRockit JVM.
`jconsole`	Yes	`jconsole` works with the JRockit JVM. The JRockit Management Console in JRockit Mission Control (see The JRockit Management Console) is however a better tool for monitoring the JRockit JVM.
`jrunscript`	Yes	No equivalent, `jrunscript` works with the JRockit JVM.

Command-line Option Compatibility Between the JRockit JVM and Sun

This section describes the compatibility between command-line options available when running the JRockit JVM and when running the Sun Hotspot JVM. These options correspond to each other by name only, by function only, or both by name and function.

Table 5-2 lists options that both Sun Hotspot JVM and the JRockit JVM have but have different functionality depending upon the JVM you are running.

Table 5-2 Same Name, Different Function
Option Name	Hotspot Function	JRockit JVM Function
-`Xms`	Sets the initial size of the heap	Sets the initial and minimum size of the heap. For complete description, please refer to `-Xms`.

Table 5-3 lists options that work the same or similarly on both Sun Hotspot and the JRockit JVM but have different names depending upon the JVM you are running.

Table 5-3 Different Name, Same or Similar Function
Hotspot Option Name	JRockit JVM Option Name	Function
`-XX:+AggressiveHeap`	`-XXaggressive:memory`	Configures the memory system for memory-intensive workloads and sets an expectation to enable large amounts of memory resources to ensure high throughput. The JRockit JVM will also use large pages, if available.
`-verbose:gc`	`-Xverbose:memory`	Prints out log information about the memory system
`-Xmn, -XXNewSize, -XXMaxNewSize`	`-Xns`	Sets the size of the young generation
`-XX:+UseConcMarkSweepGC`	`-Xgc:singlecon`	Sets the garbage collector to use a concurrent strategy
`-XX:+UseParallelGC`	`-Xgc:parallel`	Sets the garbage collector to use a parallel strategy

Table 5-4 Options Available for JRockit JVM Only
Option name	Function
`-XgcPrio`	Specifies what to prioritize: even pause times or maximum throughput
`-XpauseTarget`	Specifies a suitable pause time for the application

Submitting Migration Tips

The migration tips discussed in this section represent an evolving list. Often, a successful migration to the JRockit JDK depends as much upon the application being migrated as it does to the VMs being used. Oracle welcomes suggestions based upon your experiences with migrating applications to the Oracle JRockit JDK. Feel free to submit any migration ideas or comments to the Oracle JRockit forums at dev2dev.

Diagnostics Guide