The dreaded “java.lang.OutOfMemoryError: PermGen space” exception.
Frank Kieviet has two excellent posts that explain the dreaded “java.lang.OutOfMemoryError: PermGen space” error and more importantly how to use some new Java 6 tools to diagnose the source of the problem. The first post in particular highlights a very subtle issue with classloader/reference handling that anyone developing code for multiple-classloader environments needs to be aware of.
Alessandro Ribeiro also has an interesting three post piece where he shows how to use the JDK 1.5 ‘jps’ and ‘jstat’ tools to help diagnose the same problem (hint: “jstat -gcpermcapacity
Users have been running into this when running Eclipse-based products on Sun’s JDK 1.5 for some time and Eclipse Bug 92250 has been quietly collating lots of feedback and suggestions from the Eclipse community along the way. A lot of people have been lurking/waiting/hoping that someone would identify the source(s) of the issue and produce a fix so it is good to see increased activity there. However, the recent debate about whether this is a Sun or Eclipse (where I found links to the above blog posts - thanks Karsten!) issue might be a little discouraging but it appears there is acknowledgement that some responsibility lies within the Eclipse community to help diagnose the problem.
I’d imagine many adapters would be willing to lend a hand in diagnosing this since it is a potential stability issue for all Eclipse based products when run on what is the de-facto Java VM. However, I suspect any such analysis effort would need to be done in coordination with some platform/WTP folks since they would need a good insight into the expected behaviour of all of the active bundles to be able to determine which are at fault (or if indeed the fault lies with the VM)
What intrigues me about this issue is that Eclipse/Equinox doesn’t normally destroy classloaders so classloaders not getting garbage collected can’t be the source of the problem. But with that assertion, how can any application be hitting a 512Mb permGen limit? It does smell of a VM bug but then why doesn’t it happen with other Java based applications? Clearly some feature common to many Eclipse applications is rubbing the Sun VM up the wrong way.
I guess the only way to find out is to do a very deep analysis but a pre-requisite for that is to find a simple use case that can reliably and repeatedly reproduce the problem. We don’t seem to have one with our product but perhaps someone else out there does.
on 05 Apr 2007 at 4:00 pm # Ismael Juma
Regarding the 512MB limit, look at the following comment. Due to a mistake from the user, the limit had not actually been increased from the default of 64MB.
Even though it’s possible that there’s a leak on the eclipse side, it’s also very possible that eclipse with several plugins simply needs more than 64MB of PermGen.
Also relevant is that few people have problems after increasing the max PermGen size (so there’s no continuous leakage).
In my opinion, Sun should either increase the default max PermGen size or provide a standard option to allow applications to increase it (instead of the “subject to change” option that exists now).
In addition, it would be nice if eclipse was able to configure the Sun VM to use a higher max PermGen size automatically.
on 05 Apr 2007 at 4:13 pm # Alex Blewitt
The PermGen space is set aside for the permanent generation, which includes all intern()’d String literals. These also make up the constants used in Java .class files, so if you have a program that has a lot of String constants, the PermGen can fill up quite quickly. It’s that, more than anything, that causes the issues; and these aren’t reclaimed by ClassLoaders dying.
The fact is that Sun have invested absolutely no time in making the memory processes more flexible; instead, various arbitrary ‘maximums’ are defined when the process starts, even if there might be more memory available. A decent system should have no problem in dynamically allocating more PermGen space if needed; Sun’s VM code (and all that use it) think one fixed-size-for-all works well.
In any case, to answer Ismael, it’s possible for the option to be added to eclipse.ini — but it can’t be added by default, since the presence of a non-standard option would prevent other VMs (e.g. IBM’s, Apple’s) from starting up (since they don’t understand the opton). And because Eclipse is inclusive, they can’t do that by default.
The problem is basically Sun’s hard-coded default is too small for today’s apps, and there’s talk of it being upped in future releases of the JVM — but for now, hand-editing the eclipse.ini is the way forward.
on 05 Apr 2007 at 5:27 pm # Ismael Juma
Alex, I am aware of that and it has been discussed in the bug. However, this problem causes a lot of problems for new users. Just hang around in #eclipse (IRC channel) and you will see the amount of people who come there due to that problem. The worst case is when the VM does _not_ crash and simply consumes 100% of a cpu.
So, in my opinion, it would not be a bad thing if eclipse had a way to identify a given VM and specify specific arguments for that VM.
Having said that, I do agree that the main issue is with Sun’s maximum default and I believe I made that clear in my post. Also, it’s not really true that the Sun VM cannot allocate more PermGen memory. It has a starting value and a maximum value like the heap. It’s unknown to me why they made the maximum value so low though. Possibly to fail fast in case of classloader leaks, but it’s obviously inappropriate for current applications.
on 05 Apr 2007 at 6:33 pm # aehso
Ismael,
My bad on the 512Mb limit link, but there are other comments (e.g. #77) that refer to 256m limits being exhausted. This backs up anecdotal reports that we are getting from our Cape Clear Studio users (WTP 1.5.3 based) even though we install an .ini file that specifies
-vmargs
-Xms256m
-Xmx512m
-XX:MaxPermSize=256m
out of the box.
Alex: interesting comment on the intern’ed string literals, but still, you are inferring that a hell of a lot (or a few very large) of intern’ed strings get created.
It would be interesting to find out who or what is intern’ing any significant volume of these strings and whether they could use some other flyweight-type mechanism to optimize reuse of string values, instead of stuffing them into the VM to live forever.
It’d be *very* interesting to see if anyone is doing silly things like intern’ing xml document instances. But in the absence of a quantifiable analysis this is all really all pure speculation.
I agree to some extent that there should be some standard controls for these limits (and perhaps the default should be higher) but perhaps this whole issue is being driven by a couple of pieces of bad code that could potentially exhaust any limit (like the hosts physical memory capacity).
on 05 Apr 2007 at 8:57 pm # Andrei Loskutov
Here are two interesting links related to permgen:
http://my.opera.com/karmazilla/blog/2007/03/13/good-riddance-permgen-outofmemoryerror
http://my.opera.com/karmazilla/blog/2007/03/15/permgen-strikes-back
on 26 Apr 2007 at 11:56 am # Brian
Thanks for the info Aehso. Please let us know when there is a fix for this.
on 16 Jan 2008 at 12:01 am # Submundo Java » Arquivo eclipse.ini para evitar o tão odiado “java.lang.OutOfMemoryError: PermGen Space” Exception.
[...] se por um acaso alguém quiser saber mais detalhes sobre este problema, recomendo a leitura do POST dreaded “java.lang.OutOfMemoryError: PermGen space” error. [...]