Migrating to JRockitJan 25 2009
I’ve been bothered with the now famous PermGen Space error while developing a web application on a local jetty instance quite often, and I was hoping that the problem wouldn’t prove to be that serious once deployed on a tomcat server, but quite the opposite is the case.
The problem happens when the JVM runs out of permanent generation heap space, which most of the time is due to classloaders not being correctly garbage collected. Permanent generation heap space is an optimization that the Sun JVM contains to speed up object creation, but the default size is too small if classes are loaded and unloaded often during runtime, which is exactly the mechanism most application servers load applications. So the first, quick and dirty, solution would be to enlarge the permanent generation heap space:
-XX:MaxPermSize=256m. Sadly, this still doesn’t get rid of the problem. Another solution is to use a completely different JVM altogether: JRockit.
JRockit, a proprietary Java Virtual Machine (JVM) from BEA Systems, became part of Oracle Fusion Middleware in 2008. Many JRE class files distributed with BEA JRockit exactly replicate those distributed by Sun. JRockit overrides class files which relate closely to the JVM, therefore retaining API compatibility while enhancing the performance of the JVM. [from Wikipedia]
I wasn’t thrilled having to change JVM because it isn’t available in the openSuse repositories at all, and I wasn’t quite sure how hard it would be to make the switch. As I found out, it’s incredibly easy.
Getting the package
Getting your hands on the JRockit installation package isn’t all that easy, because BEA became part of Oracle and everything is still in transition. The download location is http://edelivery.oracle.com/, where you’ll be greated by a wizard to select the products to download. JRockit can be found under BEA Products and then BEA WebLogic Media Pack, scrolling down you’ll find the zip package you need depending on your operating system.
Installation is straight forward, just unzip the archive and then execute the contained installer:
$ unzip B46961-01.zip Archive: B46961-01.zip inflating: jrockit-R27.5.0-jdk1.6.0_03-linux-x64.bin $ chmod +x jrockit-R27.5.0-jdk1.6.0_03-linux-x64.bin $ sudo ./jrockit-R27.5.0-jdk1.6.0_03-linux-x64.bin
Now all you have to do is follow the instructions of the installer. When asked for a location to install JRockit into, I used
/opt/jrockit but every location will do just fine. The next step is optional, but if you use
update-alternatives I strongly suggest you to do it. We’ll add jrockit java and the the jrockit compiler (javac) as alternatives:
update-alternatives --install /usr/bin/java java /opt/jrockit/bin/java 300 update-alternatives --install /usr/bin/javac javac /opt/jrockit/bin/javac 300
So when doing an update-alternives we see the jrocki VM:
$ update-alternatives --config java There are 2 programs which provide `java’. Selection Command ----------------------------------------------- + 1 /usr/lib64/jvm/jre-1.6.0.u7-sun/bin/java * 2 /opt/jrockit/bin/java
Enter to keep the default[*], or type selection number: so now we can easily switch between the Sun VM and the JRockit VM. That’s it. Now just check to see if we really have the JRockit VM and we’re ready to code:
$ java -version java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) BEA JRockit(R) (build R27.5.0-110_o-99226-1.6.0_03-20080528-1505-linux-ia32, compiled mode)