Java: Why does MaxPermSize exist?

Question

Why does MaxPermSize exist?

Answer 1

Here is a good article on the Permanent generation in the Garbage collector:

Presenting the Permanent Generation on Jon Masamitsu's Weblog

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 :)