the corner office

I've been plodding on with Sun's 1.5 JVM, and constantly running into out-of-memory errors. I nudged the Xmx arguments upwards and upwards, but that didn't seem to help. It turned out I wasn't getting the usual heap-related out of memory error - I was getting this:

java.lang.OutOfMemoryError: PermGen space

This prompted a bit of research, and me learning a bit more about the Sun JVM's permanent generation, which is distinct from the 'normal' generations which are stored in the heap. The permanent generation is used to store class files and the like, (or as the JVM docs say, "it holds data needed by the virtual machine to describe objects that do not have an equivalence at the Java language level.") It seems that 64-bit JVMs are even more susceptible to outgrowing the default perm space settings than their 32-bit counterparts, and a number of people complaining about the PermGen space errors mention they're using AMD64s. Eclipse ain't the smallest app around, and by the time you add monstrous plugins like MyEclipse, you've got quite a few classes loaded into memory. (I redirected -verbose:class output to a text file, and just opening and clicking around a few perspectives in Eclipse loaded well over 6,000 classes).

The solution is to adjust the PermSize and MaxPermSize settings using the -XX:PermSize and -XX:MaxPermSize VM arguments. I can't find confirmation of what the default space is for the AMD64 JVM, and how much I should increase it by, but I'll be playing around with the settings and see how it goes.

Useful links:

• TSS: Explaining and Fixing java.lang.OutOfMemoryError: PermGen.
  
• TSS: Detecting Memory Problems Before they Hurt. Comments section has some interesting 'PermGen' discussion and sample code to recreate the error.
  
• Sun: Tuning Garbage Collection with the 5.0 Java[tm] Virtual Machine
  
• EclipseZone: Tuning Eclipse Performance and Avoiding OutOfMemoryExceptions. Also suggests setting start and max heap and perm space settings equal to each other to speed things by avoiding resize overhead. Not sure if this is voodoo, one commenter says it makes a tangible difference).
  
• Netbeans Performance FAQ: OOME section says: "Usually maximum allowed size (96MB as specified by -XX:MaxPermSize option in etc/netbeans.conf file) in NetBeans should be adequate for 32-bit VM. It can be necessary to increase size of this area if 64-bit JVM is used."