-XX:MaxPermSize
From Resin 3.0
Line 10: | Line 10: | ||
The value for MaxPermSize is specified in the resin.conf: | The value for MaxPermSize is specified in the resin.conf: | ||
<code><pre> | <code><pre> | ||
− | <jvm-arg>- | + | <jvm-arg>-XX:MaxPermSize=512m</jvm-arg> |
</pre></code> | </pre></code> | ||
Revision as of 19:49, 8 April 2008
MaxPermSize specifies the the maximum size for the permanent generation heap, a heap that holds
objects such as classes and methods.
Several Resin users have found excessive garbage collection times even when there is plenty of heap space available as reported by -J-verbosegc. In many of these cases, increasing the MaxPermSize solves the issue.
Because MaxPermSize is a maximum size, it is safe to increase even if it is not known that the application will actually need that space.
The value for MaxPermSize is specified in the resin.conf:
<jvm-arg>-XX:MaxPermSize=512m</jvm-arg>
There are some <jvm-arg>
option in the default resin.conf, the option above is added beside them.
MaxPermSize and debuggers (agents)
The JDK's permanent memory behaves differently depending on whether a debugging is enable, i.e. if there is an active agent.
If there is an active agent, the JDK can fail to collect permanent memory in some cases. (Specifically, when some code introspects a class with a primitive array like, byte[]
or char[]
.) This can cause the permanent space to run out, for example, when redeploying .war files.
From the JDK source code (systemDictionary.cpp):
// Update: if a Java program cycles through a lot of class loaders // and the classes loaded by those class loaders have a lot of // primitive arrays, then the perm gen explodes in size. For now, // we revert back to Merlin (1.4.0) behavior and only save this // information if an agent is currently attached.