-XX:MaxPermSize with or without -XX:PermSize

Question

We've run into a Java.lang.OutOfMemoryError: PermGen space error and looking at the tomcat JVM params, other than the -Xms and -Xmx params we also specify -XX:MaxPermSize=128m. After a bit of profiling I can see occasionally garbage collection happening on the PermGen space saving it from running full.

My question is: other than increasing the -XX:MaxPermSize what would be the difference if I specify as well -XX:PermSize? I know the total memory then would be Xmx+maxPermSize but is there any other reason why -XX:PermSize should not be there when -XX:MaxPermSize is specified?

Please do share if you have real-world experience dealing with these JVM parameters.

ps. The JVM is HotSpot 64bit Server VM build 16.2-b04

Hornstein

you need to care about the max only, waste of the energy and the entropy b/c of this very question will never come close to saving of "perfectly" tuning the jvm. maxPerGen is important and specify any arbitrary high value, the jvm wont commit before it actually needs. – Cliffhanger

Answer 1

-XX:PermSize specifies the initial size that will be allocated during startup of the JVM. If necessary, the JVM will allocate up to -XX:MaxPermSize.

Onia

true. It also makes the difference that the total memory appears as Xmx+maxPermSize which is very important. That's why I am asking whether there is anything else going on. – Hornstein

The total memory consists of more than mx and maxperm. Especially you get some memory (stack) for each thread. If you have thousands (which is not a good thing) this can be up to 50% of the overall size. There might also be excessive native heap when you have some JNI implementations (for example oder SAP JCO drivers). And some compoennts use the off-heap direct mapped memory in addition. – Odontoid

Answer 2

By playing with parameters as -XX:PermSize and -Xms you can tune the performance of - for example - the startup of your application. I haven't looked at it recently, but a few years back the default value of -Xms was something like 32MB (I think), if your application required a lot more than that it would trigger a number of cycles of fill memory - full garbage collect - increase memory etc until it had loaded everything it needed. This cycle can be detrimental for startup performance, so immediately assigning the number required could improve startup.

A similar cycle is applied to the permanent generation. So tuning these parameters can improve startup (amongst others).

WARNING The JVM has a lot of optimization and intelligence when it comes to allocating memory, dividing eden space and older generations etc, so don't do things like making -Xms equal to -Xmx or -XX:PermSize equal to -XX:MaxPermSize as it will remove some of the optimizations the JVM can apply to its allocation strategies and therefor reduce your application performance instead of improving it.

As always: make non-trivial measurements to prove your changes actually improve performance overall (for example improving startup time could be disastrous for performance during use of the application)

Couplet

Thanks. I'm astound to see how diametrically opposite the views are on this (look at @mijer response) even in various other places. I understand this since we don't really know what this flag is doing and how it is interacting with the other one unless we study the c code of the JVM. That's why I was looking for hands-on real-life experiences. – Hornstein

The "don't do things like making -Xms equal to -Xmx" comment is not shared by all users. Tomcat specifically recommends setting them to the same value. tomcatexpert.com/blog/2011/11/22/… – Saw

@JohnHinnegan Setting it to the same value does have its advantages (such as less garbage collection during startup), but as I said in my answer it will prevent the JVM from making some optimizations. And in that event you will either have to live with it or do those optimizations yourself with the commandline options of the JVM. – Couplet

+1 with Mark, don't do that upfront. Re-posting: to try to explain a bit why that "set -Xms=Xmx" value is so much spread, I think this is due to the fact that many years ago the JVM was much less capable of autoadaptation. Nowadays, I'd recommend to do that as a last resort after a serious phase of perf testing. Indeed, the JVM has gotten very good in autoadaptation, and JVM-world known expert for example Kirk Pepperdine tell that setting those values upfront would be like asking a musician to play with one hand bound in your back (heard in a training). – Siloam

It's probably a good advice to not apply Xms=Xmx as a recipe. But in some cases it can be the good choice, it depends what you want to optimize. Do you want to optimize the application throughput or its memory fingerprint? – Gavel

Can you be more specific about from which version or date of JVM is much more autoadaptive with Xms<Xmx setting? – Barbel

@Barbel iirc, that started with Java 5, and it has improved which each version – Couplet

Answer 3

If you're doing some performance tuning it's often recommended to set both -XX:PermSize and -XX:MaxPermSize to the same value to increase JVM efficiency.

Here is some information:

1. Support for large page heap on x86 and amd64 platforms
2. Java Support for Large Memory Pages
3. Setting the Permanent Generation Size

You can also specify -XX:+CMSClassUnloadingEnabled to enable class unloading option if you are using CMS GC. It may help to decrease the probability of Java.lang.OutOfMemoryError: PermGen space

Blancmange

Thanks. I'm astound to see how diametrically opposite the views are on this (look at @Mark Rotteveel response) even in various other places. I understand this since we don't really know what this flag is doing and how it is interacting with the other one unless we study the c code of the JVM. That's why I was looking for hands-on real-life experiences. – Hornstein

See also GC Tuning Java 6 Setting -Xms and -Xmx to the same value increases predictability by removing the most important sizing decision from the virtual machine. On the other hand, the virtual machine can't compensate if you make a poor choice. – Couplet

To try to explain a bit why that "set -Xms=Xmx" value is so much spread, I think this is due to the fact that many years ago the JVM was much less capable of autoadaptation. Nowadays, I'd recommend to do that as a last resort after a serious phase of perf testing. Indeed, the JVM has gotten very good in autoadaptation, and JVM-world known expert for example Kirk Pepperdine tell that setting those values upfront would be like asking a musician to play with one hand bound in your back (heard in a training). – Siloam

I work on low-latency applications for several years. There is no simple performance recipes, it depends what we want to optimize (cost, latency, ...) I frequently applied Xms=Xmx to improve performance. This tuning is relevant when it doesn't make sense to let the JVM does complex calculations to adapt its consumption because we book underlying resources. Obviously this needs a serious phase of thinking/testing, not only to put the good tuning on the Java command line, but also to buy the good underlying hardware. – Gavel

3rd link's broken FYI – Rub