Should I set a MaxMetaspaceSize?

Question

So, after asking this question, it quickly became clear that the important question was not "how can I", but "should I"?

We have customers that we are moving from Java7 to Java8 (using Tomcat7). Java7 required setting the -XX:MaxPermSize, and some customers have increased their max above the default set by the installer due to individual needs and uses.

Should I set the -XX:MaxMetaspaceSize (to the previous -XX:MaxPermSize setting) for customers who have defined a custom max? What about new installs? Should we set -XX:MaxMetaspaceSize at all?

What are the pros and cons of such a decision?

Answer 1

As I commented on the previous answer the reasons for setting a limit on those memory pools is different.

If your users previously increased the MaxPermSize above the default that probably was either to avoid Full GCs / concurrent mode failures with CMS or because their applications genuinely needed a lot of perm gen space.

Decreasing the the metaspace limit from its effectively infinite default would serve an entirely different purpose: Avoiding unbounded metaspace growth.

The thing is that that's just an upper limit. The actually committed, i.e. current metaspace size will be smaller. In fact, there is a setting called MaxMetaspaceFreeRatio (default 70%) which means that the actual metaspace size will never exceed 230% of its occupancy.

And for it to grow it first would have to fill up, forcing a garbage collection (metaspace full) in an attempt to free objects and only when it cannot meet its MinMetaspaceFreeRatio (default 40%) goal it would expand the current metaspace to no more than 230% of the occupancy after the GC cycle.

So in practice the actual metaspace size should stabilize within a band close relative to its actual need unless the application is continuously leaking classloaders/classes or generating an enormous amount of dynamic code.

TL;DR: There may be reasons to restrict metaspace size, but they likely are different to the original reasons for setting the perm gen sizes. Therefore the need should be re-evaluated.

Answer 2

Just to air the opposite opinion, the case can be made to ALWAYS set the MaxMetaspaceSize. Grouping the world's entire set of applications into 10 (binary - think about it) groups allows a discussion of why. Remember though, setting the limit only controls when Garbage Collection (GC) of that space will occur.

Group 01: Applications with all Non-Dynamic Classes

This group puts you into the stabilized band referred to above. In this case, the size to set is fairly easy to determine (just as MaxPermSize was) and there won't be much, if any, GC anyway.

Group 10: Applications with Dynamic Classes

Given the proliferation of highly powerful third party libraries, isn't almost every application in this group anyway? Often you don't care if the library is Scala/Groovy/etc, it just does exactly what you want so it is used. What is the value of filling up Metaspace with the litter of dead (dynamic) classes? When GC does come, it will be expensive. I would rather limit the size, make GC more frequent (but less pause time for each), and more easily run multiple applications on the same hardware without having concerns about their individual metaspaces running into one another.