Using WebLogic Server with the WebLogic JRockit JVM

By default, the installation process of WebLogic Server installs the Java 2 Platform Standard Edition (JDK1.3.1) with the Java HotSpot JVM which is licensed from Sun. All other J2EE APIs are included in the weblogic.jar file, which is located in WebLogic Server's software library directory ( WL_HOME\server\lib ).

A high percentage of WebLogic installations prior to the release of WebLogic Server 7.0 used this default Java 2 Platform to execute their J2EE applications. However, on February 25, 2002, BEA Systems Inc. announced the acquisition of Appeal Virtual Machines AB, a leading Java Virtual Machine (JVM) software company. Appeal's product, the JRockit JVM, is specifically designed for enterprise server-side execution of Java applications and includes pioneering technology around I/O, memory management, and multi-threading , which results in industry leading scalability, manageability, and performance. The JRockit JVM is currently engineered for Intel and Linux machines, and work is underway to support a more diverse hardware platform.

The acquisition of Appeal Virtual Machines and the JRockit JVM leads to a high probability for future versions of the WebLogic Platform, including WebLogic Server, to include the JRockit JVM as the JVM of choice for selected hardware architectures. For this reason, this chapter includes a discussion on the option to use the JRockit JVM with the WebLogic Server.

The Benefits of Using the JRockit JVM

A JVM is critical to your implementation of WebLogic Server because WebLogic Server is an instance of the weblogic.server Java class, which contains the main() method, executing within the context of the JVM. There can be multiple JVMs installed on a machine; however, every instance of WebLogic Server will run in its own JVM.

In general, the specifications for the Java Virtual Machine are relatively open for implementation by software vendors . The specifications define core features every JVM must possess:

A class loader that loads the required Java API and program class files into the JVM.
A memory stack area called the heap.
A memory garbage collection routine.
An execution engine that compiles Java bytecode to native machine instructions.

By design, how these features are implemented is left to the architects of the JVM. This well-thought out approach allows the JVM specification to be flexible enough to be implemented on a wide variety of computers and devices as well as in software, such as Java IDEs and applications servers.

Most JVMs have their foundations in client-side environments, and have slowly been modified to support the demands of the server. It is extremely important for you to understand that JVMs are optimized quite differently for client-side and server-side usage. BEA's research has shown that each of these environments place different demands on the JVM as follows :

Client-side JVM demands
- 75% in translating and executing bytecode.
- 20% in garbage collection.
- 5% in threads and I/O- related activities such as socket communication, files, and databases.
Server-side JVM demands
- 25% in translating and executing bytecode.
- 15% in garbage collection.
- 60% in threads and I/O-related activities such as socket communication, files, and databases.

JRockit is the first commercially available JVM that has been engineered from scratch to support server-side Java applications with the following design features:

Superior server-side performance compared to any other JVM.
Full Java compatibility with J2SE 1.3.1 and J2SE 1.4.
Support for 32-bit and 64-bit architectures.
Full support for dynamic class loading.
Support for the core design goals of the JVM, which enables optimizations, thread scheduling policies, and memory management policies to be written in Java and added to the JVM at runtime.
Full adaptive optimizatio n of the execution engine, enabling JVM runtime statistics to improve code optimizations, garbage collection, and thread management.
A bottleneck detector that constantly collects runtime statistics. If a method is executed frequently and found to be a bottleneck, it is sent to the Optimization Manager subsystem for aggressive optimization. The optimized method then replaces the old method dynamically. Hence, the bottleneck detector can continuously improve the performance of a Java application.
Two different thread systemsHigh Performance and Native threads.
Four different garbage collection schemes.
A management console that enables administrators to monitor the real-time operating characteristics of the JVM and the executing Java applications, enabling CPU and memory utilization problems to be proactively identified and resolved, which can otherwise contribute towards application downtime.

Installing and Using JRockit with WebLogic Server

JRockit is currently freely available for anyone to use without restriction, and therefore does not require a license key to activate it. You can download the JRockit installation program (20MB) certified for either J2SE 1.4 or 1.3.1 to a directory on your machine from the BEA Web site using the following URL:

http://commerce.bea.com/downloads/weblogic_jrockit.jsp

After you have downloaded the JRockit installation program, execute it and follow the directions presented to install JRockit to a directory on your machine. The JRockit software installation files are approximately 40MB in size.

After you have installed JRockit, you can make JRockit the default JVM for your machine by adding the full path of the JRockit bin directory to your system's PATH variable, ensuring the JRockit path occurs before the path to any other JVM. Alternatively, you can use the full path to the JRockit Java executable when starting a Java program.

Caution

On Windows 2000, some programs set the system default JVM by copying a java.exe file to the C:\WINNT\system32 directory. If this happens and the C:\WINNT\system32 directory is listed before the path to JRockit in your system PATH variable, you will probably be running a different JVM than expected. You can test which version of JVM you are using by executing java -version from the command prompt.

To switch WebLogic Server to use the JRockit JVM instead of the default HotSpot JVM, follow these steps:

Open the WL_HOME\server\bin\startWLS.cmd file with any text editor.
Edit the line "set JAVA_HOME=" to point to the fully qualified path to your JRockit JDK installation directory, for example:
```
   
```
```
  set JAVA_HOME=C:\Program Files\JRockit\7.0\1.3.1  
```
Remove the text %JAVA_VM% in the line near the end of the file.
Save the file.

Before you start up your WebLogic Server with JRockit, it is extremely important that you verify if you were using any X command-line options to start the HotSpot JVM. The -X command-line options are used to change the behavior of the HotSpot JVM and are typically stated as values for the MEM_ARGS variable in the startWebLogic.cmd script file. Even though standard command-line options available for JRockit are the same as HotSpot, such as -version and -help , the nonstandard options (-X options) for JRockit are in most cases not the same as the nonstandard options for the HotSpot JVM. If you were using any X command-line options to start the HotSpot JVM, you will need to review the syntax for implementing the same or similar feature for JRockit from the JRockit User Guide.

Tip

It is highly recommend you review the X command-line options for JRockit because this is how you configure its behavior.

Using the JRockit Management Console

The JRockit Management Console can be used to supervise and monitor running instances of the JRockit JVM, providing real-time information about the characteristics of Java applications. For example

During development, you can use the management console to locate where in an application's lifecycle more memory is consumed.
In a production environment, the management console can be used to monitor the health and resource utilization of the WebLogic Server.

The extra resource cost of running the JRockit Management Console against a running JRockit JVM is very small and can almost be disregarded, which provides an excellent means for monitoring and profiling your J2EE applications in conjunction with the WebLogic Administration Console.

Before you can use the JRockit Management Console, the management server inside the JRockit JVM, which is disabled by default, needs to be started. The management server provides the means for the management console to connect to the JRockit JVM via a port, which by default is set to 7090.

To enable the management server, you will need to start JRockit with the managementserver property set to true . This can be achieved by editing your startWebLogic.cmd script file and including the -Djrockit.managementserver=true value for the JAVA_OPTIONS variable, as follows:

 set JAVA_OPTIONS= -Djrockit.managementserver=true

You can optionally modify which port to use by setting the port in the port property, as follows:

 -Djrockit.managementserver.port=<  portnumber  >

After you have modified the JAVA_OPTIONS variable accordingly , you can start your WebLogic Server using the startWebLogic.cmd script file. After the management server is successfully started, you will be notified with the following message in the command console:

 [JRockit] Management Server started on port 7090

To start the JRockit Management Console, ensure your PATH is set correctly to point to the JRockit installation directory, and type the following from the command prompt:

  java -jar ManagementConsole.jar

After the JRockit Management Console starts, you will need to connect it to the JRockit JVM associated with your running WebLogic Server using the following steps:

From the Connection menu, select the New Connection option.
In the displayed Add New Connection dialog screen, enter the following information, as illustrated in Figure 10.22:
- The IP Address or DNS of the machine where the JRockit JVM is running.
- The Port number on which the management server is running.
Select the Connect Now option and click Add Connection.

After you have connected the JRockit Management Console to the JRockit JVM, you will see a screen similar to Figure 10.23, from where you can use the Overview, Memory, Processor, System and Notification tabs to monitor in real-time the different aspects of the JRockit JVM.

Figure 10.23. Monitor the JRockit JVM in real-time using the JRockit Management Console.

graphics/10fig23.jpg