Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8072061

Automatically determine optimal sizes for the CDS regions



    • Enhancement
    • Status: Closed
    • P2
    • Resolution: Fixed
    • 9
    • 10
    • hotspot
    • b21
    • Verified



      To improve the usability of CDS, we should eliminate the need to manually configure SharedReadWriteSize, SharedReadOnlySize, SharedMiscDataSize and SharedMiscCodeSize. Currently, these 4 values specify the size of 4 regions of the CDS archive. The user must set them "big enough" to contain all classes metadata.

      In JDK-8048150, we added some code to guess the needed size based on the number of classes in the classlist. However, the guess is overly pessimistic but still not precise. So it would usually waste a lot of virtual address space, yet in rare cases would fail to reserve enough space.

      The virtual address space waste is problematic on 64-bit platforms with class pointer compression. The 4 CDS regions sit at the beginning of the class space. If the CDS regions are excessively large, it will leave less space for allocating InstanceKlasses at run time, and would lead to failure to load classes (as we have seen in corner cases with JavaScript engines).

      Currently, to have the "correct" region sizes requires trial and error. You need to dump the archive once to find out how much space is needed, and then dump the archive again with the correct sizes. Such "curation" of archives is inherently incompatible with cloud deployments, where arbitrary Java applications are deployed and any type of application-specific (manual) configuration is undesirable.

      The usability problem becomes even worse as we plan to support 2-level CDS archives in JDK 10. Therefore, the JVM needs to automatically choose optimal sizes for the archive regions without user involvement.

      Design Overview

      During CDS archive creation:

      1. Load all the classes in the class-list. Allocate their class metadata using the "regular" metaspace allocators.

      2. Iterate over all reachable class metadata objects so we know what objects should be archived. Note that some metadata objects created in step 1 would be subsequently freed (due to rewriting, etc) so we should not include these in the CDS archive.

      3. Copy the RO objects into the RO region. The size of the RO region becomes fixed at the end of this step.

      4. Copy the RW objects into the RW region. The RW region immediately follows the RO region.


      + Simplify the usage of AppCDS (no need to use preset RO/RW region sizes.), especially with planned 2-level archives in JDK 10.
      + As a next step, during the copying phase (#4 above), we can segregate the frequently and rarely used methods. Since only about 30% of loaded methods are actually used, doing this will allow us to reduce the runtime memory usage.
      + As a side effect, the added functionality to iterate over class metadata objects will enable various new tools such:
          + Detailed size statistics (improvement over the existing ClassStatsDCmd)
          + Detection of memory leaks in the Metaspace.

      As discussed in the comments below in this bug report, the JVM could be programmed to "dump twice" to first determine the size of the regions, and then do the final dumping. This would be an automation of the manual steps described in the "Justification" section above.

      However, this has several issues:
      1. We need to spawn a child JVM process to do the "trial" dumping, and then pass various sizing information back to the main process.
      2. The main process still doesn't know how to eliminate freed/unreachable objects from the archive. These currently consists about 1.5% of the archive size, and will become an even larger percentage as we plan to run the Java-based class loader for dumping the archive (up to 5%).


        Issue Links



              iklam Ioi Lam
              iklam Ioi Lam
              0 Vote for this issue
              9 Start watching this issue