Summary

Today we must explicitly generate a CDS archive in a separate "dumping" step. Also, if the application or the JDK is updated, the CDS archive needs to be manually updated. To improve usability, we should allow the CDS archive to be automatically generated or updated.

Solution

Introduce a VM option, -XX:+AutoCreateSharedArchive. When this flag is enabled for running with a dynamic shared archive, if the archive file is non-existent, out-of-date or damaged, we automatically generate or update the shared archive at VM exit. This flag must be used with -XX:SharedArchiveFile=<archive_name>.

Specification

java -XX:+AutoCreateSharedArchive -XX:SharedArchiveFile=<file> ....

• The default value of AutoCreateSharedArchive is false.
• -XX:+AutoCreateSharedArchive may be used only with -Xshare:auto. It cannot be used with -Xshare:on.
• If AutoCreateSharedArchive is true, SharedArchiveFile must be specified, or else the VM will exit with an error message.
• If AutoCreateSharedArchive is true, and the CDS archive <file> can be successfully loaded, the VM will use the archive without regenerating it.
• Otherwise: the VM takes the actions described in the following section.
  • If <file> doesn't exist, it will be created
  • If <file> exists, it will be regenerated if:
    • it is a valid dynamic archive file that was generated by JDK 18 or later, and
    • it is out of date (because the JDK or the application has been updated)
  • Otherwise, we have a damaged archive, a system error, or a user error. We should warn the user and do not update the archive. The application will be executed without loading <file>.