Question

Assuming a 64-bit JVM, is there any significant benefit to keeping MaxPermSize small?

This is in the context of a Java EE application that is frequently redeployed, and has a classloader leak. As a medium-term workaround, it seems very reasonable to just bump up MaxPermSize to an absurd value – as long as it won’t blow out the disk swap space.

Because the undeployed app’s code is nearly all unused (apart from that involved in the leak), it’s paged out by the operating system. So the load on physical memory from undeployed detritus seems negligible; this has been verified by observing RSS (the working-set size on Unix).

Are there other effects I should be concerned about?

Answer 1

From JVM HotSpot FAQ

Should I increase the size of the permanent generation in the client vm?

This will always be a judgment call. In general increasing the size of a generation (and this applies not just to the permanent generation) can reduce the incidence of a wide variety of problems However, this may cause other processes to excessively page and/or garbage collect or throw out-of-memory exceptions.

There are two failure modes to consider.

When raising MaxPermSize, it is possible that previously well behaved programs that used to garbage collect to recover the permanent generation space will die by endless paging. For the permanent generation this usually only happens with the heavy interning of temporary strings.

The other failure mode is that address space must be reserved for the permanent generation and this will reduce that available for the rest of the heap (the maximum -Xmx may then be too large). This will cause programs configured to use all available space to fail at initialization.

Also this article says :

So we take advantage of the fact that classes are kept in the permanent generation by collecting the permanent generation before collecting the tenured generation. And the permanent generation is currently collected serially.

Large permanent generation can cause longer time of GC I think.