Forum Stats

  • 3,826,747 Users
  • 2,260,702 Discussions


Another different solution to the "PermGen space issue" -comments solicited

John Stegeman
John Stegeman Member Posts: 24,269 Blue Diamond
edited Apr 1, 2009 2:22PM in JDeveloper and ADF
Hello all,

I've been participating in [url]another thread where the infamous permanent generation space (PermGen) has come up again. Olaf H noted that the JRockit JVM by design isn't prone to these types of problems. So, I got to thinking - how can we leverage JRockit for JDeveloper development. I know that JRockit is a supported JVM for WLS, but there's no information about using JRockit to run JDeveloper (in fact, there are a few issues - mouse scroll wheel issues for one). So, how can we use the Sun JDK (either the bundled one with JDev or our own already installed one) to run JDeveloper and use JRockit for running the integrated WLS. It turns out to be pretty simple.

What I did (Windows Vista):

1). Install JRockit
2). Edit the <JDEV_HOME>/jdeveloper/system/system11. file (the same one you edit to increase the max perm gen size):
a). add a line "SET JAVA_VENDOR=BEA"
b). edit the line that starts "set BEA_JAVA_HOME" to point to the JRockit installation

I noted the following:

1). the integrated WLS used JRockit (verified in the log file and by using task manager to make sure the java.exe process running was the JRockit one).
2). (also a verification of #1) - I was able to use JRockit Mission Control against the running WLS (cool)
3). Simple debugging seems to work (breakpoints, step, look at variables, etc).
4). I verified that the startup of WLS doesn't pass in the max perm gen size parameter (although I did shrink it back to 48m, "just in case")
5). (most importantly) - I tested 10 change-run-test cycles without restarting the integrated WLS - no errors!
6). (added after some thought) - it appears that the WLS starts up and shuts down a bit slower with JRockit - but no hard data to back this up. This may just be my brain looking for a downside.

Now, for the big question - licensing. Would this configuration (using JRockit for development only, not in production) require a license payment to Oracle, or can we, under the OTN license that you accept when downloading JRockit, use this freely for development? The OTN license reads, in part:
We grant you a nonexclusive, nontransferable limited license to use the programs for purposes of developing your applications that work with the programs.
So, it appears that we can use this configuration. It would be a big benefit to not have to work around the perm gen space all the time.

Second question - it seems that this should be a fully supportable configuration, correct?

Comments always welcomed.

Full credit to Olaf Heimburger for putting this train of action in my mind.





  • bkummel
    bkummel Member Posts: 215
    Hi John,

    Thanks for sharing this. I downloaded and installed JRockit yesterday and changed my environment following your instructions. I had to restart JDeveloper to get it working. But it works and I didn't have any OutOfMemoryException until now. On my PC there is no notable difference in the startup time of the embedded server.

    Bart Kummel
  • User_HWHT9
    User_HWHT9 Member Posts: 2,858 Employee
    Hi John

    My $0.02 worth.

    I guess if Olaf's analysis is correct that increasing the permGen size wont solve the issue, and JRockit is immune from the problem, it makes sense to pursue JRocket as a solution. However (without attempting to be rude to Olaf) is it the correct analysis?


  • John Stegeman
    John Stegeman Member Posts: 24,269 Blue Diamond
    edited Apr 1, 2009 5:04AM
    @Chris: Good point. I believe Olaf to be correct based upon:

    1). Another poster made a comment to Shay's blog entry on increasing the perm gen space essentially saying the same thing (JRockit is immune). I have noted that increasing the max permgen size just postpones the issue when doing intensive code->run->test->repeat cycles.

    2). I have done a cover-to-cover to read of the JRockit documentation, paying particular attention to how it manages memory and does garbage collection. I believe this to be true

    3). Googling "JRockit permgen" finds lots of nuggets like this:
    The simplest workaround (short of tracking down the sources of memory leaks in the app itself)
    suggested to replace Sun’s JVM with BEA’s JRockit. JRockit doesn’t have a PermGen heap so there can be no leaking there.
    @Bart - can you clarify your meaning of "until now?" Do you mean you haven't had any of the errors at all, or you haven't had them as frequently (normally, I would interpret "until now" as "I haven't had any of those errors until just now")

    Thanks for the feedback both

  • bkummel
    bkummel Member Posts: 215

    Sorry, I did not realize that my sentence was ambiguous. I meant that I did not have any memory error at all since I switched to JRockit.

    Best regards,
  • florinmarcus
    florinmarcus Member Posts: 35
    Thanks John,

    I have tested and is working.

    This should boost our productivity,

    Florin Marcus
  • John Stegeman
    John Stegeman Member Posts: 24,269 Blue Diamond
    OK - I have found one issue that I cannot resolve, but it's easy enough to ignore, so I thought I'd at least post here so others can benefit.

    I have an ADF BC/Trinidad app - it uses an Oracle DB. When I try to debug this app (WLS is using JRockit), I get a couple of NullPointerExceptions in JdbcOdbcDriver (lines 96 and 113). The debugger breaks, and since I don't have the source code for JdbcOdbcDriver set up, I get some dialog boxes asking me if I want to configure tracing. I just answer "no" and continue execution, and things work fine after that.

    I don't get this error when running (as opposed to debugging) the app; neither do I use the JDBC/ODBC bridge, so it's confusing as to why it happens, but it's workable to live with it. It only happens if the WLS isn't started up yet when I debug - if it's already running, no issues. The other unusual thing: the error happens during the deployment of the application, but yet the debugger catches it and breaks...

  • Timo Hahn
    Timo Hahn Senior Principal Technical Consultant - Oracle ACE Director Member, Moderator Posts: 38,458 Red Diamond
    One other thing I found, is that you can't just recompile small changes in a source. The changes are not picked up automatically, you have to restart the debugger.
    I always get the message that the new class could not put into the running process because of a schema change. This is not the case when I use the Sun JDK.

This discussion has been closed.