| By Kunal Mittal | Article Rating: |
|
| November 6, 2003 12:00 AM EST | Reads: |
18,785 |
The need for a server-side JVM is evident. The increase in the number of Java applications on the servers, and the exponential rise in the number of clients accessing these Java applications, brings forth the shortcomings in the traditional Java VMs, which are more tuned towards client-side processing.
The first question that comes to mind when talking about JRockit is the comparison between the JRockit JVM and the Sun JVM. Although this article does not focus on this distinction, I will present a brief history of JRockit and then discuss the management and monitoring features introduced in it.
A few of the major issues with these JVMs are their ability to handle threads, the time taken for garbage collection, and the management of I/O operations. In a typical client-side application profile, 75% of the time a client JVM is running code, 20% of the time it's managing memory (garbage collection), and the remaining 5% of the time it's dealing with threads and I/O activity. On the server side the JVM spends about 25% of its time running code, 15% of its time managing memory, 30% managing threads, and 30% performing I/O.
JRockit was introduced by Appeal Virtual Machines, based in Stockholm, Sweden, and acquired by BEA in 2002. JRockit offers alternative thread management and memory management to fit the needs of these server-side applications. It also introduces a more adaptive code optimization based on runtime monitoring information. JRockit is fully J2SE certified. A handful of core classes have been modified for better performance, but the majority of classes are unchanged from the Sun JVM.
Interpreter Versus Compiler
A key distinction between JRockit and traditional JVMs is that JRockit does not interpret code. Instead it uses a fast JIT compiler to compile all methods it encounters. The result of this is slower start-up times and a larger memory footprint, but faster execution times in the long run. During execution, a background thread is constantly looking for frequently run code. Such code is aggressively optimized and replaced during runtime. This is called adaptive optimization.
Runtime Management Console
JRockit comes with the JRockit JVM Management Console, which currently is not included with any of the commonly used JVMs. The management console comprises a management server and a standalone Swing application that is the console. You can turn on the management server by passing the following flag to the JVM on start-up:
"-XManagement"
An interesting note is that the console can be used with any JVM, not just JRockit. You can start the console by using the following command:
"java -jar <jrockit-installdirectory>/
console/ManagementConsole.jar"
Figure 1 shows how you can use the console to connect to the server.

Figure 1: JRockit connection
I have changed the default Medical Records application that ships with BEA Platform 8.1 to use the JRockit JVM. Figure 2 shows the command window when the BEA WebLogic Server is starting up. Note on the top that I have enabled the JRockit management server. Towards the bottom of the window you can see that I am connecting to the management server using the management console.

Figure 2: WebLogic startup command window
When you talk about monitoring, there is always a performance impact that you have to accept when you are monitoring information. The JRockit management console can be run on the server or a remote machine, thereby reducing the overhead on the server. However, there is still some overhead on the monitored JVM. I recommend running the management console to monitor the JVM when needed (when you see problems) and then disconnect, so that there is minimal impact on the monitored JVM. The console has a notification feature that can trigger alerts based on thresholds for various variables. A few interesting events are
- CPU Load
- % of Used Heap
- Free Physical Memory
- JVM Absolute CPU Load
- % of Used Memory
- Average Time Spent in GC

Figure 3: Monitoring information
The console also allows profiling of userspecified methods, showing the number of times a given method is invoked. This is roughly like a profiler, but the user must specify the class and method. Similarly, the console can be used to count the number of times an exception was thrown. The user must specify the exception to be counted.
Integration with the WebLogic Console
Many developers, and especially the operations departments, complain that they have to use still another console. This is not true with JRockit. The standard WebLogic console integrates with the JRockit management server. You can get the same monitoring capability that you get using the JRockit management console through the standard BEA WebLogic console. However, remember that the WebLogic console can also be used to monitor the JRockit JVM, not any other JVM. This is primarily due to the lack of available monitoring features in other JVMs.
JRockit Runtime Analyzer Tool
The JRockit JVM is instrumented to provide runtime behavior regarding the Java application. Such information was not available previously. Various tools take an outside-in, after-the-fact approach on trying to extract such information by hooking into the JVM. The inside-out approach taken by JRockit provides more accurate information with less performance impact.
The JRockit Runtime Analyzer is used by BEA engineers internally to tune and refine the JVM. Only recently has BEA opened this to the entire BEA community. You can download this tool from the BEA site and use it to analyze your own Java applications.
Summary
This article talked about the management and monitoring capabilities of the JRockit JVM. Although monitoring always has some impact on performance (and don't believe anyone who says otherwise), the ability to monitor your applications through your development life cycle and in production environments is key. Monitoring allows you to quickly identify and pinpoint problems and defects. The rich data that monitoring can provide can have a huge impact on the overall robustness of your applications.
References
Published November 6, 2003 Reads 18,785
Copyright © 2003 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By Kunal Mittal
Kunal Mittal is a consultant for implementation and strategy for Web services and services-oriented architectures. He has co-authored and contributed to several books on Java, WebLogic and Web services.
- The Economics of Cloud Computing Analyzed
- GovIT Expo Highlights Cloud Computing
- Cloud Computing Best Practices
- Tactical Cloud Computing Panel at 1st Annual GovIT Expo
- Why SOA Needs Cloud Computing - Part 1
- The Cloud Transition: What Does It Mean For You?
- Cloud Computing Strategy
- IBM’s Mainframe Monopoly Threatened by BMC Founder’s Shop
- Economy Drives Adoption of Virtual Lab Technology
- Virtualization Expo Call for Papers Deadline December 15
- Oracle in Leader's Quadrant for Enterprise Application Servers
- Oracle Fusion Middleware Delivers World Record Single-Node Result
- The Economics of Cloud Computing Analyzed
- The Difference Between Web Hosting and Cloud Computing
- GovIT Expo Highlights Cloud Computing
- Cloud Computing Best Practices
- Tactical Cloud Computing Panel at 1st Annual GovIT Expo
- Citrix Aims To Cripple VMware’s Cloud Designs
- Product Evaluation: JBoss TCO Calculator
- Why SOA Needs Cloud Computing - Part 1
- Build Reliability into Cloud Computing for SMBs
- Perhaps SOA is More Strategy Than Architecture
- EC Wrong, Wrong, Wrong – and Sloppy to Boot: Intel
- Five Reasons to Choose a Private Cloud
- Java vs C++ "Shootout" Revisited
- Where Are RIA Technologies Headed in 2008?
- Configuring Eclipse for Remote Debugging a WebLogic Java Application
- Migrating a JBoss EJB Application to WebLogic
- XA Transactions
- The Top 250 Players in the Cloud Computing Ecosystem
- An Introduction to Abbot
- WebLogic Tutorial: "Integrating Apache Poi in WebLogic Server"
- Eclipse "Pollinate" Project to Integrate with Apache Beehive
- Failover and Recovery of Enterprise Applications - Part 1
- Cover Story: A Practical Solution to Internationalization of a J2EE Web App
- WebSphere vs WebLogic: IBM and BEA Spar Over SPEC Results






























