Sizing permanent area of JVM

[David Gourley]

I've done some testing, and if the permanent size (controlled with -XX:MaxPermSize= and -XX:PermSize= command line options to the JVM) is not big enough, you appear to end up getting an java.lang.OutOfMemoryError when the ClassLoader attempts to load a class into the permanent area (and this causes subsequent application problems). As classes are loaded on demand, and there are techniques that can be used to defer loading of classes (e.g. using reflection), and by default application classes appear not to be unloaded from this area (verified by turning on -verbose to the JVM), it appears critical to size the permanent area to avoid potential stability problems.

Short of ensuring 100% code coverage (including potentially 100% code coverage of any libraries used), does anyone have any good sizing ideas/methodologies for the permanent area? (We're currently using 1.4.2.08).

[Steven E. Protter]

If you can afford the time, I'd recommend a graudual approach.

Keep increasing the memory allocation in increments until you reach a state where operations are stable. Then make an allowance for peak usage to give yourself some buffer space.

SEP

[David Gourley]

Steven, I understand this approach. My concern is that without understanding levels of code coverage (including in (say) database libraries etc.) it's difficult for me to convince myself that I've peaked out usage.... I've seen situations where permanent area size suddenly grows very rapidly several days into a test run because some code path has suddenly been executed for the first time... This is particularly of concern if areas perform deferred loading of error-handling code which pulls in other classes (as often not all error paths are executed until a long way through a test run).