-XX:MaxPermSize
From Resin 3.0
Line 9: | Line 9: | ||
The value for MaxPermSize is specified with the [[Command Line Options]] -XX:MaxPermSize=''size'' | The value for MaxPermSize is specified with the [[Command Line Options]] -XX:MaxPermSize=''size'' | ||
+ | |||
+ | == 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, <code>byte[]</code> or <code>char[]</code>.) 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. |
Revision as of 20:47, 5 April 2006
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 with the Command Line Options -XX:MaxPermSize=size
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.