Disregarding class space, metaspace consists of a list of individual mappings. Traditionally, individual mappings had been rather small (2 root chunks => 8 MB). That is because the mechanism to release metaspace memory to the OS had been to unmap unused mappings, and the larger the mappings were the smaller the chance of them being completely unused, due to fragmentation.

We recently did away with this old release mechanism in favor of a new one with finer granularity (see JDK-8275582). So there is no motivation anymore to keep mappings particularly small.

There are however good reasons to enlarge them:
- less fragmentation on the OS mapping level (e.g. on Linux, number of VMAs would go down, has a number of advantages)
- Larger mappings -> fewer of them -> list gets smaller, which is good for functions iterating this list (e.g. `Metaspace::contains()`, see JDK-8275704).

The effect of larger mappings is an increase in the step size with process *virtual size* will grow. So, before vsize grew in 8MB steps, now those steps are larger and rarer. In total we should not use much more vsize than before. Larger mappings would have no effect on committed memory size.

And note that vsize is pretty much irrelevant with modern OSes. For our hotspot on 64-bit, it is astronomical anyway, so this change would have no impact in real life.

The only exception are 32-bit platforms, where address space itself is limited, so this change should only affect 64-bit platforms.