Relates :
|
(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).