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.
