JDK-8242426 : Deprecate InitialBootClassLoaderMetaspaceSize
  • Type: CSR
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 15
  • Submitted: 2020-04-09
  • Updated: 2020-05-18
  • Resolved: 2020-05-15
Related Reports
CSR :  
Description
Summary
-------

Deprecate the VM product option InitialBootClassLoaderMetaspaceSize.

Problem
-------

In the context of the upcoming "Elastic Metaspace" work, InitialBootClassLoaderMetaspaceSize makes no sense and can be removed.

In Metaspace, Class Loaders obtain chunks of memory to store Metadata via pointer bump allocation. When a chunk is used up, a new chunk is allocated for the Class Loader.

InitialBootClassLoaderMetaspaceSize determines the size of the first chunk to be given to the Boot Class Loader. It does not impose any limit, since when that chunk is used up a new one is allocated. 

So this is purely a performance optimization: the default value for InitialBootClassLoaderMetaspaceSize is large (4MB), and the purpose of giving a large chunk to the Boot Class Loader is to minimize the number of follow up chunk allocations which are perceived as expensive. The underlying assumption is that the Boot Class Loader will load a large and usually static number of classes and use up that large initial chunk as much as possible.

Even in the current Metaspace implementation this switch is not really useful and can actually be counter productive:

- The default size is guesswork and subject to bitrot. For example, with the advent of CDS the Boot Class Loader loads a smaller number of classes than when the switch was introduced; hence the initial chunk is too large and not completely used up. This leads to unnecessary memory waste. A more fine granular chunk allocation would be more memory conservative at the cost of few more cpu cycles. In fact, many blogs on the Internet recommend lowering this value to decrease initial memory footprint [1].

- The savings in startup time are too small to measure. Setting InitialBootClassLoaderMetaspaceSize to a small value does not have any measurable effect on startup time, so the optimization is not really needed.

In the context of the upcoming Elastic Metaspace, InitialBootClassLoaderMetaspaceSize makes even less sense. Now, larger chunks will be committed on demand by their class loader, similar to thread stacks. In the new scheme, the Boot Class Loader can be given a large initial chunk whose size is fixed and does not have to be influenced by the user. That initial chunk is committed piecemeal as class loading happens.

Solution
--------

Add a warning that the InitialBootClassLoaderMetaspaceSize switch is deprecated in JDK 15, and will be made obsolete in JDK 16 according to our process of removing command line options.

Specification
-------------

In JDK 15, the -XX:InitialBootClassLoaderMetaspaceSize option will print a deprecation warning, in the next release, use of -XX:InitialBootClassLoaderMetaspaceSize will no longer have any effect on Metaspace allocation. Instead, using this option will print the usual obsolete option warning.


-------
[1] https://shipilev.net/jvm/anatomy-quarks/12-native-memory-tracking/

Comments
Moving to Approved.
15-05-2020

Moving to Provisional.
13-04-2020

This looks great.
10-04-2020