Wednesday, July 14, 2010

Permgen problems and Running Eclipse on Java 1.6 update 21

People running Eclipse on windows using the latest Java 1.6 update 21 jvm from Oracle/Sun are noticing frequent vm crashes or freezes:
Unhandled event loop exception
PermGen space
As indicated in the Eclipse FAQ, there is a simple workaround for this problem, edit your eclipse.ini file and add -XX:MaxPermSize=256m below the -vmargs line:

History and Explanations

Starting as far back as Eclipse 3.1 it was noticed that Eclipse uses a lot of "PermGen" memory under Sun VMs. Permgen memory is where .class file information is stored. The way to avoid this memory problem is to increase the permgen size by using -XX:MaxPermSize.

The problem is that this is a non-standard vm argument and can cause vms from other vendors to not start at all. We eventually fixed this by introducing a new argument in the eclipse.ini file: --launcher.XXMaxPermSize.

When this argument is specified, the eclipse executable launcher tries to identify whether the vm is from Sun or not. If the vm is Sun, then the launcher adds the -XX:MaxPermSize vm argument. On windows, we identify Sun vms using the GetFileVersionInfo API. We read the version information from the java executable (or jvm.dll) and check to see if the company name is "Sun Microsystems".

This worked great and everyone was happy. Fast forward a few years and Oracle acquires Sun. Now starting in Java 6 update 21, the company name in the jre is Oracle. This means the launcher no longer recognizes the vm as being from Sun and the -XX:MaxPermSize vm argument no longer gets applied results once more in Permgen memory problems.

The fix for this change is being tracked in bug 319514.


Unknown said...

Problen solved Andrew, thanks a lot!!!

Nico said...

Does anyone have an explanation as for why a lot PermGen memory is used with Oracle/Sun VMs?

I believe this contains String interns, and .class information.
Does that mean everything referenced by a static pointer?

Gabriel Belingueres said...

Nice explanation!

A good exercice is to think who to blame for this is eclipse's fault for relying on a .dll property (a not pure Java thing)? or it is oracles's fault for changing this (changing the version number is enough I think)?

I miss the "Write once, Run anywhere" days haha!!


Rush said...

WOW. it worked !! thanks you are a life saver :D

Ganesh said...

Thanks Andrew,

I was facing this issue on my new machine causing lot of frustration, loss of productivity, miss-trust etc etc, now i can tell my boss..."That wasn't my bug"