Max Rydahl Andersen
A couple of months back I made a blog entry about Eclipse and its memory settings. I wrote it because so many people complained that even when they put memory flags in their eclipse.ini Eclipse was still a memory hog and it crashed all the time. The entry blog explains how fragile eclipse.ini is and how to write it correctly and verify that it is picked up correctly.
That helped many, but suddenly I was starting to see more and more blogs, jira issues, forum postings, phone calls, personal assaults etc. about Eclipse memory usage sucking and our users started having memory issues with the latest builds and releases of JBoss Tools.
Why were so many seeing memory issues on a release that actually should use less memory than the previous one ?
As it turns out, on top of the issues with eclipse.ini from my previous entry, Eclipse 3.3.1 introduced a major bug in parsing the settings in eclipse.ini that resulted in PermGen memory settings not being set correctly on Sun Java VM's!
Result: Eclipse 3.3.1 runs "fine" at first, but as soon as you start having larger projects and/or using additonal plugins you are bound to get OutOfMemoryExceptions!
Thankfully eclipse.org is now in the process of doing a respin of Eclipse 3.3.1 and the first build is now available for testing.
So what do you do if you like your Eclipse 3.3.1 and don't want to try the build from above ?
You have a couple of options:
- Use the *exact* settings described in my previous blog - they are not affected by the Eclipse 3.3.1 bug
- Use Red Hat Developer Studio which automatically uses the settings described in my blog
- Use another VM, only Sun's and Apple's VM requires the PermGen setting; IBM's and JRockIt JVM allocates PermGen space dynamically