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.