Using BEA WebLogic JRockit^TM with NetBeans 4.0

Introduction

Why do we need another JVM?
Well this question is not easy to answer because definitely not every body needs it. So to make a first cut: Only developers of Java applications and Java based web applications might want to read this article and might be interested. But also Administrators and Operators of highavailable Websites might find something here.

If you've ever tried to use the profiling of the JVM or wanted to have a deeper look into what is going on in your virtual machine while your program is allready running, you might run into the problem that the information provided by the VM is very low level. You will have a hard time to go into the depths of analysing the data that is produced by the VM. (For instance if you switch on the -Xprof parameter of the JVM 1.4.x or the -agentlib:hprof of the JVM 5.0)

And some information might not be available any way, even if you use the profiling. One solution to that problem could be, that you write your own profiling agent. Java gives you access to deep VM information through the Java Virtual Machine Profiler Interface (JVMPI). But that means that you'll have to implement your own profiling in a native way. There is - as far as I know - no standard java way to access lowlevel profiling informations.

If you use JRockit you'll not have to worry about this. There is the so called "Console" that ships with JRockit and gives you direct access to vital informations of the applications that run in your JVM. Even to the point that it estimates execution times of single methods, gives you an overview of the most used classes and counts exceptions thrown.

Is it for debugging only?
That's a definite "NO". JRockit has been designed and optimized for intel platforms to achieve best performance and reliability. It serves as JVM for the BEA WebLogic Server.

I don't want this to be another product presentation of BEA, so I suggest, if you are interested in JRockit and/or the WebLogic Server details, please follow this link.

How do I exploit it?
There are basically two ways. Once you've installed the JRockit JDK you can develop and execute Java Applications with out even noticing, that you are using a different JVM except that you might notice a considerable performance boost to some of your applications. It is to be mentioned that if you program nonsense, there is no way that your program executes any faster than before. So we are not talking about magic! ;-)

1. The first major advantage you might want to exploit is that the JRockit Console gives you access to fine granular information collected somewhere in the depths of the JVM. You'll understand how to use and instrumentalize the Console for your application in a later chapter.
2. The second advantage is that you'll use the JRockit Runtime Analyzer (JRA) to collect information during runtime. If you are using JRockit in a production environment, this tool can give you access to the necessary information during runtime without restarting the application. Specifically in a web environment where it is impossible just to restart an instrumentalized version of the server that becomes very important.

Download

To download the JRockit environment you'll have to access the website of BEA Systems, Inc. http://www.bea.com or you just click here to access the download area directly.

The JRA must be downloaded separately via http://www.bea.com/framework.jsp

The documentation for the JRA and JRockit itself are also interesting, available through the link http://edocs.bea.com/jrockit/webdocs/index.html

Installation

After the download you'll need to install your JRE and/or the JDK.

After that a call to java -version should give you something like this:

java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-win-ia32, R25.0.0-75, GC: System 
optimized over throughput (initial strategy singleparpar))

Nothing more is to do.

If you are using different JDK's from different vendors at the same time I suggest to create batch files that switch the used JDK to the appropriate one.

Configuration

Entry point for the configuration is the etc/netbeans.conf. You'll find it in your NetBeans installation directory. In that file you'll have to change the lines:

# default location of J2SE JDK, can be overridden by using --jdkhome dir  switch
netbeans_jdkhome="C:\Programme\Java\jdk1.5.0"

to

# default location of J2SE JDK, can be overridden by using --jdkhome dir switch
# netbeans_jdkhome="C:\Programme\Java\jdk1.5.0"
netbeans_jdkhome="C:\Programme\Java\jrockit-jdk1.5.0"

You might need to adjust the paths to the proper installation directories of your JDK installation. If you change it here, please be sure that you are not using the --jdkhome switch.

To provide access to the console, the JVM must be started with a commandline switch called -Xmanagement. You can add this also in the etc/netbeans.conf file to the line

netbeans_default_options="-J-Xms32m -J-Xmx250m -J-Xverify:none -J-Xmanagement"

to start NetBeans itself with the management option. Then you are able to analyze NetBeans' JVM, Garbage Collector and see into the details of what has been programmed for the IDE ;-)

That's it. Now you are using JRockit as JVM for NetBeans - wasn't so hard, eh?

After restart of NetBeans you should find under Help->About in the details section a screen that looks like this one:

Since the time stamp of the src.zip of JRockit can be different from your JDK installation, NetBeans might need to scan that again. But this will only happen once.

Usage

There is a certain amount of additional parameters that can be used to tweak JRockit. Here is a comprehensive list, but please access hhttp://e-docs.bea.com/jrockit/jrdocs/refman/index.html for a detailed description.

    -Xgcprio:[throughput|pausetime]
              sets prio for the gc-system
                  throughput    optimizes the gc-behavior to achieve optimal
                                throughput (initially starts off with
                                single-spaced parallel GC mode but may switch
                                to other GC modes dynamically during runtime)
                  pausetime     optimizes the gc-behavior to achieve minimal
                                pause times (initially starts off with
                                single-spaced concurrent GC mode but may switch
                                to other GC modes dynamically during runtime)
    -Xcleartype:[alloc|gc|local]
              defines which type of clearing should be performed
                  alloc         starts at allocation time (default)
                  gc            starts when the gc is running
                  local         starts when you get to a local area
    -Xgc:[singlecon|gencon|parallel]
              used to set a static garbage collector
              will override the options -Xgcprio, -server, and -client
                  singlecon     use the single-spaced concurrent garbage
                                collector algorithm (default in client mode)
                  gencon        use the generational concurrent
                                garbage collector algorithm
                  parallel      use the single-spaced parallel
                                garbage collector algorithm
                                (default in server mode)
    -Xms<size>[g|G|m|M|k|K]
              sets the initial Java heap size (ms)
                  server mode:  the default value is 25% of the amount
                                of free physical memory in the system
                                up to 64 MB with a minimum of 8 MB (default)
                  client mode:  the default value is 25% of the amount
                                of free physical memory in the system
                                up to 16 MB with a minimum of 8 MB
    -Xmx<size>[g|G|m|M|k|K]
              sets the maximum Java heap size (mx)
                  server mode:  the default value is the smallest of 75% of
                                physical memory and 1536 MB (default)
                  client mode:  the default value is the smallest of 75% of
                                physical memory and 64 MB
    -Xns<size>[g|G|m|M|k|K]
              sets the initial Java nursery size for generational collectors
                  server mode:  the default value is 10 MB per (default)
                  client mode:  the default value is 2 MB
    -Xss<size>[g|G|m|M|k|K]
              set initial stack size
    -Xpausetarget=<optimal_pause_time>[ms|s]
              JRockit will optimize the pause time to the given target,
              uses -Xgcprio:pausetime
                  ms            pause time specified in milliseconds (default)
                  s             pause time specified in seconds
    -Xnoclassgc
              disable class garbage collection
    -Xgcpause
              print pause times caused by the garbage collector
    -Xgcreport
              write extensive memory report at end of run
    -Xdebug
              enables debugging support in the VM
    -Xjvmpi:[<argument1>=<value1>[,<argumentN>=<valueN>]]
              enable/disable groups of jvmpi events when running jvmpi
                  entryexit     (default on)
                  allocs        (default on)
                  monitors      (default on)
                  arenadelete   (default off)
    -Xmanagement
              enable the management server needed by the
              JRockit Console
    -Xnoopt
              do not optimize code
    -Xstrictfp
              always use strict floating point calculations
    -Xnohup
              used to not process CTRL_LOGOFF_EVENT or SIGHUP events
    -Xrun<library>
              loads and runs a library
    -Xverbose[:memory|codegen|load]
              enable verbose output
    -Xverboselog:<file>
              log verbose output to a file
    -Xverbosetimestamp
              adds a timestampt to the verbose printout
    -Xverify
              do full bytecode verification

Console

The console is the vital part of the information retrieval. When you start it the first time, you'll see nothing. Well too bad... You'll have to connect to a JRockit instance. The standard port of the connection is 7091 which is by default also the management port for remote administration of the JVM.

Remark: So if you start an application with JRockit in -Xmanagement mode, you'll be able to connect with Sun's jconsole Tool to the JVM and manage all Management Beans (MXBeans). Thats also very handy. But consider, that the Sun jconsole is not the JRockit console: Two different tools!

So you create a new connection using the button or the menu "New Connection...". A dialog pops up where you can enter the needed informations:

As you can see, this works also remotely. So if you are on a management dedicated computer and you want to monitor your Web Application Servers running on JRockit on a different server somewhere in the network, you can do so remotely unless no firewall restricts access to the ports.

If the connection could be established, the console is allready collecting data. And you'll see in the Overview section an image like this:

Very interesting from a developers point of view, specifically for the developers of the NetBeans platform itself, is the method profiler. It counts invocations of specific methods and collects execution times.

Profiling sessions are organized by named templates. In each template you can define specific objects to observe. You just provide in the dialog that opens after you pushed the add button the full qualified class name of the class you would like to monitor and in a second step you'll be asked to select from a list the methods to be monitored. You have to consider that monitoring of abstract or native methods is not supported. After that hit the start button and wonder how fast the numbers increase. Then you'll know where the execution time goes to...

On the "Memory" tab of the JRockit console you are able to manage the memory that is currently used by the JRockit Process. It is possible to lock the heap size or you can resize the the heap during runtime. That is also a nice feature if you are not able to restart your application at your will.

In the system tab you get some informations of the runtime environment of the JVM you are looking at. Very neat is the feature that you can tie Virtual Machine processes to specific Processors on a multi processor plattform. If you have one...

Notifications might only be sensefull if you are monitoring a high available platform and you want to be notified automatically by the system if the heap size reaches a specific amount or the CPU load exceeds 90% or something like that. You can define listeners in this tab for such events and define what should be done in such a case. Typically an email would be send out to an emergency administrator account.

The last tab is the exception counter. If you provide an exception class name, all exceptions of this type thrown will be counted. This might be of interrest if you have well dedicated exceptions where you exactly know in which cases such an exception is thrown. Counting highlevel exceptions might scare you but you might not be able to extract some valuable information out of this.

JRockit Runtime Analyzer

The runtime analyzer targets specifically people who are not able to restart a server for debugging or runtime analysis. Specifically people like Administrators of 24/7 websites. Since this is not the target for NetBeans developers, it is just briefly described here.

The tool is designed to collect data starting at a specific time and for a specified amount of time. Before and after this, the JVM is running like if you where not collecting any data. So there is nothing to worry about loosing performance due to instrumentalization of the JVM. It is so deeply implemented that you'll be unable to recognize any difference during runtime when runtime analysis is switched off.

The profiling will create an XML file on the machine that runs the JVM. The JRA tool then is designed to analyze offline the collected data.

The collection process is started with a commandline tool called "JraRecordingStarter.jar" it needs some arguments. A simple call could be:

java -jar JraRecordingStarter.jar localhost 7091 myrecord.xml 300

Where you provide the target host where the JVM is running, the management port, the name of the created XML file and the recording time in seconds.

The created XML is zip'ed after it is completely flushed to disk.

Then you are able to use the RuntimeAnalyzer to analyze the created results:

Also the executed garbage collections during the time of recording can be accessed and measured. Be aware that my recording was very short in time and there was not much to collect. So in a real scenario you can see much more information.

There is a problem currently in the JRockit 5.0 Release. It appears as an error message in the NetBeans Status field:

It has something to do with a final package local method being overridden in a different package. It is a bug in JRockit with the current release. And it is supposed to be fixed in the next patch release. So you'll have to wait or ignore. What ever fits you best ;-)

Unfortunately this error has impact on the NetBeans usage. You might not be able to access your java source files in the project view pane. How ever you can access them through the file view instead. But that is really anoying. Good news: This error has been reported to BEA and they mentioned in the developer forum that this error should be fixed with the next patch release.

So I suggest you wait until the next patch release of JRockit.

JRockit is a high performance JVM that works pretty good with NetBeans. I have been very supprised how fast actually the classpath scanning can be finished. Also improved startup time of NetBeans is definitely a plus.

One might argue that there is not really a need for developers to switch the JVM but if you are a so called "early adopter" you should definitely give it a try. It's worth it specifically if you are using NetBeans on a daily basis.