Monday, October 15, 2007

2.2.1 Memory Woes

Show of hands, how many of you have upgraded to version 2.2.1 of BIRT? Okay, now how many of you have had memory issues? Based on my experience and the messages on the newsgroup, it seems like almost everyone that has moved to 2.2.1 through installation of the new All-In-One build is having this problem. Fortunately, there is an easy fix. The problem is related to a change in the Eclipse.ini file. This is a bug on the entire platform and affects all of the Eclipse products, not just BIRT. To fix open the Eclipse.ini file in your ECLIPSE_HOME directory. Find the line with

-launcher.XXMaxPermSize=256m

Replace that line with
-XX:MaxPermSize=256m

That should solve the problem. The platform team is tracking this bug here. They are trying to make a decision
to release a new version of the platform or not. The BIRT team is also tracking the issue here.

Depending on what the platform team does with a new release, we may create a new 2.2.1a build of BIRT so that
this problem does not continue to exist.

Updated: It has come to my attention that there could be a couple of issues.
First) -XX:MaxPermSize=256m has to be the last line in the eclipse.ini
Second) There is only a single dash before the XX:MaxPermSize

Here is the complete eclipse.ini that I am using on my system. I have bumped the memory numbers a bit since I have plenty of RAM on my system.


-showsplash org.eclipse.platform
-vmargs
-Xms128m
-Xmx512m
-XX:MaxPermSize=256m

SR



18 comments:

sj said...

Hi,

Is this bug related to OutOfMemory error when running BIRT on OC4J server.

The error which I am getting is due to "heap size" and "permanent generation size".

If I am running OC4J server without increasing heap size, I am getting the "java.lang.OutOfMemoryError: Java heap space".

When I am running without increasing the permanenent generation size then I am getting "java.lang.OutOfMemoryError: PermGen space"

So ultimately, for running OC4J server, I have to increase both heap size and permanent generation size as below.

java -Xms512m -Xmx512m -XX:PermSize=64m -XX:MaxPermSize=256m -jar oc4j.jar

Regards,
Shomy

Patrice said...

Hi,

We have experienced the same memory issues in BIRT 2.2.1. "java.lang.OutOfMemoryError: PermGen space"

We have found that increasing the amount of perm space would extend the up time of our servers by a fraction but an OOM would always be around the corner.

As documented in the Java API, the PermSpace contains the reflective objects (Classes, Methods). We have looked into the classes loaded and have found that BIRT was instantiating a class object for each table cell there was in our reports.

These dynamic classes are staying in perm space for the life time of the JVM filling it up during each execution of a report.

The woe lies in:
org.eclipse.birt.core.script.ScriptContext

1. The compiledScripts member should be static so the Rhino scripts are cached properly after the first report execution.
2. For Thread safefy, the compileScript should be a Hastable not a HashMap.
3. The exit() method should not clear() the compiledScript.
4. Finally the eval() method should be synchronized around the script execution:
Object value = null;
synchronized (script) {
value = script.exec( context, scope );
}
return jsToJava( value );


We then recompiled coreapi.jar provided with BIRT and no longer have any memory leaks.

UMQ said...

hi,
I'm using BIRT 2.1.3 and i get this "JVM out of Memory" error.
Is it the same with 2.2.1 ??

If not then what is the solution to it?

Jason Weathersby said...

Can you try BIRT 2.2.1.1?

Patrice said...

Upgrade, upgrade, upgrade.

In this case I propose a patch to 2.2.1 that you can reproduce.

Perhaps Jason lets us know this was fixed in 2.2.1.1?!?

Alex said...

It's not fixed in 2.2.1.1

Jason Weathersby said...

Patrice,

Did you submit a bug with your patch?

Jason

Patrice said...

I did't not.
I could.
Where to?

Patrice

Jason Weathersby said...

Patrice,

Look at this link and select the report a bug or enhancement.

http://www.eclipse.org/birt/
phoenix/community.php

Thanks for doing this.

Jason

Hardik said...

i am use tomcat 5.5 and jdk 5.5
and birt 2.2
one of the report when i am try to run
it gives out of memory error
please give me solution

Madhu said...

Hi,
I have download the All-in-One 2.2.x install package from eclipse website for runnin BIRT reports. While running the reports from tomcat 5.0.x webserver i'm encountering OutofMemoryException. I have changed the eclipse.ini file as specified by you.But still the problem persists

Jason Weathersby said...

Madhu,

I assumed you downloaded the runtime and are deploying it? If so can you check the log file?

Jason

Patrice said...

I don't know what you mean by "I have changed eclipse.ini". The solution I'm suggesting has to do with updating org.eclipse.birt.core.script.ScriptContext.java and recompiling it.

Patrice

Anonymous said...

Patrice
Can you post your compiled jar?

joel sherriff said...

Jason and/or Patrice, any thoughts as to why Patrice's mods have not been adopted? (at least in 2.3.2) I'm testing them right now in an attempt to solve a similar leak.

Jason Weathersby said...

Joel,

I am not certain what bug id this has. Have you tried a later version of BIRT?

Jason

joel sherriff said...

Jason, thanks...I'm afraid we're tied to 2.3.2 at the moment but hope to upgrade sometime in the near future - we found a few too many subtle differences in the charts when we tried 2.5 that we don't have time to chase.

I'm hunting for a leak and I've always had a hunch that the dynamic classes gen'd by rhino could be a source, since #classes grows and grows and never seems to get cleaned up...but other than that, I don't have any evidence that directly points to rhino in general or ScriptContext in particular. Just wondering if Patrice's fix is known not to be a good fix.

I also have a theory that all of the deleteOnExit() calls on birt's temporary files could be leaking too and I'm currently testing that.

Jason Weathersby said...

If you find anything please open a bugzilla entry if you do not mind.