Java: Why does MaxPermSize exist?

Question

Why does MaxPermSize exist?

Answer 1

Its used to size up the maximum permanent generation. In some algos or if you use lots and lots and lots of different classes you could use this. Give this one a read.

But mostly it's used as a question in exams......

Answer 2

It exists because it helps tune the Garbage Collection subsystem within the JVM. Depending on the underlying architecture and memory management, a JVM implementation may have sub-optimal garbage collection (too thrashy for example) ... You can specify a MaxPermSize by hand rather than have it calculated so that the application behaves smoothly...

Java GC Page says more...

Answer 3

http://blogs.sun.com/jonthecollector/entry/presenting_the_permanent_generation

theres a good article on the Permanent generation in the Garbage collector.

EDIT:

I haven't seen anything that would indicate why they made the design decision to have a max limit on the permanent generation size. But i imagine it was done for several reasons.

1. It makes it much easier to implement, GCs are decidedly non trivial so simplifying your implementation in any way is probably a good idea.

2. YAGNI (You aint gonna need it) most applications load a fixed number of classes and usually its not particularly large, so they have probably optimized for the common case and just picked a sane default and left it configurable.

3. Assuming that your perm gen size is growing to be unpredictably large, then you probably have an error in a class loader (or need to rethink your architecture). Even in applications that do generate classes at run time (or do other such tricks) the number of generated classes is usually fixed as well, so you should be able to tune maxperm to fit your needs.

4. I'm no expert on all the details of java class loading and garbage collection but they are both complicated parts of the JVM so i imagine that they would try to keep these two components as orthogonal as possible, and allowing for the perm gen to grow dynamically would probably couple these two components together in complicated ways (especially because both components have serious threading considerations)

5. There are probably some performance benefits to capping the max perm generation, allowing it to grow might involve extra copying of the collection, or it might mean that your perm generation no longer exists in a contiguous address space, which could effect the way your other algorithms work for managing the collection.

Obviously these are all speculation. But even if all these are wrong i definitely don't think that it is 'idiotic' for sun to have chosen a fixed size, there are probably way more engineering and implementation considerations than i could even dream of :)

Answer 4

To present a slightly different perspective, the IBM JVM doesn't have a permgen, but rather goes out to the OS and allocates chunks of memory as it needs them. (rumor is jrockit does the same, but I can't confirm for sure.)

This is advantageous in that you're not going to hit a (seemingly) arbitrary limit and need to tune it for legitimate growth situations.

On the flip side, it's a problem for runaway apps (that essentially leak classes) - the JVM will essentially go and consume all memory in the address space. This can result in badness, where native code will suddenly fail malloc() calls, or Java breaking in odd ways - like being unable to allocate new threads (which consumes memory for the stack). Another downside is that it doesn't provide "cost certainty" about how much memory part of the JVM will consume.

So it's a tradeoff - how do you want to fail in "potential badness" scenarios?