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

-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).

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.

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.

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.