what, besides Class objects, is stored in Perm Gen Space (sun 1.6 VM)?

Question

I am seeing 'java.lang.OutOfMemoryError: PermGen space' while running ~300 JUnit tests and using Spring context. Having a tough time figuring out what's eating up PermGen since:

• in steady state the app consumes about 90m of permgen space
• I've tried -XX:MaxPermSize=256m for unit tests - still running out
• With -XX:+TraceClassLoading and -XX:+TraceClassUnloading enabled, I see no additional "loading" events while executing the last 20-30 tests before the OutOfMemoryError.

The latter seemingly suggests that something besides Class objects is filling PermGen, no? If so, what could it be? For example, are there circumstances when class instances are stored in PermGen?

Here's my VM info:

$ java -version
java version "1.6.0_25"
Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)

related

FWIW, the root of my problem that precipitated this post turned out to be somewhat trivial: I assumed that Maven Surefire plugin inherits VM settings from MAVEN_OPTS (or VM instance running mvn) when it forks a VM - it does not (boo). One has to specify those explicitly using argLine in plugin's configuration. HTH.

Answer 1

Sometimes abuse of String.intern() can cause out of PermGen space errors since interned String instances are stored in PermGen.

This might be what you are seeing - try eliminating unnecessary String.intern() calls to see if this solves the problem. In general, I wouldn't recommend using String.intern() unless you are sure that both of the following are true:

• You are sure that only a limited number of Strings will be added
• You actually need such Strings to share the same object identity (e.g. if many instances of the same strings would consume unacceptable amounts of memory or you need to rely on == for String comparison for complex performance reasons)