Q: java.lang.OutOfMemoryError: PermGen space Question:
I am using eclipse-helios and Tomcat 6 for my spring application and  get
java.lang.OutOfMemoryError: PermGen space  

WHENEVER I DEBUG MY APPLICATION
I tried

*

*Adding
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms512m
-Xmx1024m
-XX:MaxPermSize=1204m
-XX:+UseConcMarkSweepGC
-XX:+CMSClassUnloadingEnabled
-XX:+CMSPermGenSweepingEnabled
to eclipse.ini


*Creating setenv.sh and setenv.bat in tomcat_home/bin with following content
set JAVA_OPTS="-Xms256m -Xmx512m -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled"


*Manually running garbage collector in eclipse. I enabled this option by
Window -> Preferences -> General -> and select always run in background and show heap status


*Restarting Tomcat hundred times.


*Restarting eclipse and sometimes restarting my machine when frustration goes beyond the limit..
Best part is I still get the error.
Is there any solution which I should try?

I tried running other application and still get same error also IMHO my application is too small to cause error and my app is running fine on my colleagues setup.

A: Try set JAVA_OPTS=-XX:NewSize=128m -XX:MaxNewSize=256m -XX:PermSize=128m -XX:MaxPermSize=256m -XX:+DisableExplicitGC -Xms512m -Xmx1536m 

The permanent generation is special because it holds
  meta-data describing user classes (classes that are not part of the
  Java language). Examples of such meta-data are objects describing
  classes and methods and they are stored in the Permanent Generation.
  Applications with large code-base can quickly fill up this segment of
  the heap which will cause java.lang.OutOfMemoryError: PermGen no
  matter how high your -Xmx and how much memory you have on the machine.


A: Your first 3 options target 2 different JVMs. Options #1 and #3 modify eclipse JVM instance, this is the JVM managing your IDE. Option #2 modifies the Tomcat JVM instance. That's why you see two java.exe files in your task manager (in case of windows) when starting eclipse and Tomcat (assuming those are the only Java apps running).
It's important to understand that the Tomcat plugins provided by eclipse WTP (in my case Indigo) do not call the external (OS dependent) scripts to start/stop Tomcat. Instead they spawn the Tomcat JVM directly via the command line (java.exe ...). If you want to modify JVM parameters for Tomcat instances you start from within eclipse it is necessary to modify the corresponding Run Configuration. Try modifying the JVM parameters there, it should work (see screenshot).


A: What tools have you used to profile your running application? I recommend using eclipse mat, although jconsole and visualvm are available with the jdk.
Do you load a lot of classes in your application, somewhere in a loop?
How about strings? what is the size of the string pool?
I am sorry but restarting tomcat, eclipse or the machine is not going to solve the problem; you will need to profile and analyse your application to solve the issue. Take a heap dump (you can use jmap) and analyse.

A: I would add -XX:PermSize=1024m in the JAVA_OPTS variable, as the error might come from Tomcat.
I'm not familiar with the eclipse.ini file.

A: I don't know the details about eclipse.ini but I though this was just to set flags when starting Eclipse itself. Without impact on running/debugging applications. Personally, whenever I want to alter the settings when running/debugging an application, I simply add the JVM flags in the corresponding run/debug configuration.
Moreover, if you use more than 1 giga perm space, I guess there's something wrong in the code.
Try to locate the source of the perm space consumption and fix it. I don't say it'll be easy, but it'll be needed in order for the application to work properly. ...except if 1 giga perm space is really intended, but i've some doubts about it.
What you can look for is for example string.intern(). If you do this on each request/entry/whatever for arbitrary strings, you'll uselessly fill your perm space since it'll permanently keep a copy of the string.

A: For me -Xmx1024m -XX:MaxPermSize=256m did the trick.
