Using BEA WebLogic JRockitTM with NetBeans 4.0
Contributed by Stephan Kesper as part of the Win With NetBeans comptetition
A heavy user of the NetBeans IDE will experience from time to time that a classpath scanning takes more time than expected. Also he might experience that NetBeans can be resource consuming, especially on older machines. Hence it might be a good idea to search for methods to speed up the IDE. But how can this be done? Well one possibility is described here in terms of using a different JVM.
The main advantages for using JRockit is that it is optimized for performance on Intel plattforms and it ships with profiling and managing products like the console which will be described here and the JRockit Runtime Analyzer.
This article describes how to use the BEA WebLogic JRockit JVM ("JRockit") as a runtime environment for the NetBeans IDE.
JRockit can be freely downloaded and used for production or development purposes if you agree to the End-User License Agreement which can be accessed here
This article covers:
Why do we need another JVM?
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?
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?
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
InstallationAfter the download you'll need to install your JRE and/or the JDK.
After that a call to
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.
# 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
To provide access to the console, the JVM must be started with a commandline switch called
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
-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
Remark: So if you start an application with JRockit in
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.
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 300Where 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.
TrademarksBEA and WebLogic are registered trademarks of BEA Systems, Inc. BEA WebLogic Platform, BEA WebLogic Server are trademarks of BEA Systems, Inc.
All other trademarks are the property of their respective companies.