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

(draft) Unified storage for application cache (aka "new CDS workflow")

    XMLWordPrintable

Details

    • JEP
    • Resolution: Unresolved
    • P4
    • None
    • hotspot
    • iklam
    • Feature
    • Open
    • JDK

    Description

      (to be converted to proper JEP format later)

      Motivation

      Today, CDS is used to store an optimized cache for an application's class metadata and heap objects. We want to expand this storage facility to include more types of data, such as AOT-compiled methods.

      Also, over the years, the user interface to CDS (command-line and jcmd) have evolved in an ad-hoc manner. We should clean up the interface to improve usability and extensibility.

      Proposal

      The main interface is the -XX:CacheDataStore command-line switch, which specifies the location of the store. We may have other interfaces that control how the store is used.

      (Initially the store consists of a single file. In the future, it may refer to multiple files.)

      java -XX:CacheDataStore=foo.cds -cp app.jar App

      By default, if foo.cds doesn't exist, or is out of date (i.e., it was generated using a different JDK build), it will be generated/updated when the application exits. The next run of the application will be able to take advantage of the cache.

      (In the future, we may allow the cache to be automatically refined -- if the application detects that a new set of data should be cached, foo.cds may be periodically updated; (if necessary) we may even allow multiple processes to modify foo.cds concurrently).

      Initially, foo.cds is created at program exit and contains binary data (e.g., class metadata, heap objects, execution profile, AOT-compiled code, etc). We should provide some tools (or APIs) for extracting useful information from foo.cds.

      In the future, we should be able to: (a) Extract the execution profile(s) from one or multiple *.cds files; (b) Use other methods to collect execution profiles from training runs (e.g., cloud orchestration software could use serviceability tools to query the execution profile of deployed apps). Then, these profiles can be used to create a CDS file off-line.

      Clean Snapshot

      (foo.cds is created by launching a fresh JVM process and executing only code that can be safely executed ahead-of-time. We store the results of such execution as a clean snapshot into the CDS file .... more details TBD).

      Attachments

        Activity

          People

            Unassigned Unassigned
            iklam Ioi Lam
            Ioi Lam Ioi Lam
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated: