Java: Why does MaxPermSize exist?

Question

Why does MaxPermSize exist?

Answer 1

By having the MaxPermSize setting your app will throw the GC Out of Memory error at startup, so that you don't think your app is up and running and have your customers calling because the system doesn't work or is very sluggish.

Let's say you have 4gb on your VM and you know that you need 2gb of non-perm space for your app to hit the contractually agreed upon performance metrics. If your perm gen is going to take up more than 2gb, there is no point in starting the app, because you won't be able to meet your performance measures listed in your statement of work.

It is better to know that at startup, and get more memory into the box, or reconfigure your VM to take more of the physical server memory (whatever the case may be) than to start the application, allow the classes, ehcache, or whatever else to load, think everything is fine and then find out from your customers that the system is taking 10 seconds to load a page.

Answer 2

Perhaps you want to give your user the option on how much memory your application will take up, yes the OS does have a limit and will stop it anyways, but maybe the user wants to be able to limit it in the applications settings so they can do other things with that memory later on in the day without crashing your app because it's ALREADY taken up that space and can't release it because it's using it. So in the settings menu you have a "maximum amount of memory we use" slider and they can adjust it which correspondingly adjusts the MaxPermSize.

Answer 3

The permanent generation is used to hold reflective of the VM itself such as class objects and method objects. These reflective objects are allocated directly into the permanent generation, and it is sized independently from the other generations. Generally, sizing of this generation can be ignored because the default size is adequate. However, programs that load many classes may need a larger permanent generation.

PermSize is additional separate heap space to the -Xmx value set by the user. The section of the heap reserved for the permanent generation holds all of the reflective data for the JVM. You should adjust the size accordingly if your application dynamically load and unload a lot of classes in order to optimize the performance. Basically, he heap stores the objects and the perm gen keeps information about the objects inside of it. Therefore, the larger the heap, the larger the perm gen needs to be.

By default, MaxPermSize will be 32mb for -client and 64mb for -server. However, if you do not set both PermSize and MaxPermSize, the overall heap will not increase unless it is needed. When you set both PermSize and MaxPermSize, for example, 192mb, the extra heap space will get allocated when it will startup and will stay allocated.

Answer 4

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

Answer 5

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?

Answer 6

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 7

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......