Fix Version/s: 17
Compatibility Risk Description:The impact to the live process will be a short pause to collecting the class names and wait for the separate forked process finish the dump work.
Interface Kind:add/remove/modify command line option
Supply an option to jcmd to dump shared archive against live java app.
To dump a static shared archive(CDS archive), user needs first run the java app with flag -XX:DumpLoadedClassList=
<classlist>, this will write all the shareable java class names into a class list file then exit the app. Second, run with flags -Xshare:dump -XX:SharedArchiveFile=
<classlist> to dump CDS archive. The process involves two steps, get class names and dump CDS archive. If user want to dump a dynamic shared archive, they are required to run with -XX:ArchiveClassesAtExit=
<dynamic_archive_filename>, at java exit, a named archive will be created based on base archive.
CDS is helping fast startup of java app so first step is the collection of all shareable loaded class names, then run again dump the classes into CDS archive. For current methods to create shared archives, the problems are:
- User could not create CDS in one step.
- There may exist some classes which user do not want them included in CDS archive to save space. For example, the classes loaded during shutdown phase.
- User may want to dump a CDS archive at any time other than startup and shutdown phases.
- Future, we want to store method profiling data into CDS to help JIT start early. User can choose a proper time to dump the CDS when all expected methods already get compiled.
- User want to dump a dynamic archive at runtime not at exit.
Add an option to jcmd named "VM.cds" with subcommands "static_dump" and "dynamic_dump" to dump static and dynamic CDS archives respectively. The subcommand may take a parameter as shared archive file name.
For static dump, first in current thread which attached to the VM, the loaded shareable class names will be collected and written to a file whose name is based either the given name through command parameter or the process ID. Then, a child process forked to do the dump work, the child process will exit after dumping work done and the parent process keeps running. The static dump can be done multiple times against the live process.
For dynamic dump, the work can be finished in current process, but we need to record some shareable information like class loader constraints at the class loading time. A new flag is introduced, -XX:+RecordDynamicDumpInfo, for this purpose. With the flag the dynamic dumping information needed for a dynamic archive is recorded. Due to a restriction with some object pointer moved around, the dynamic dump can only be done once for the live process.
A diagnostic command named VM.cds will be added. This command will be the parent command for all commands related to CDS.
The syntax is:
jcmd <pid> VM.cds <subcommand> <filename>
filenameis optional. If omitted, a default file name will be used:
java_pid<number>_static.jsafor static dump and
java_pid<number>_dynamic.jsafor dynamic dump, where the
<number>is the process ID. For given file name, it will end with .jsa if not given 'jsa' as extension.
To use the
dynamic_dump subcommand, the application must be started with flag
-XX:+RecordDynamicDumpInfo; this flag cannot be used with
A class named DumpSharedArchiveDCmd which derives from DCmdWithParser will be added.
The permission required to start the command will be "java.lang.management.ManagementPermission" "Monitor"