Support dynamic archiving classes (including all loaded application classes and library classes that are not present in the base layer archive) as part of a Java application execution:

 - Improve the usability of application class data sharing (AppCDS). Eliminate the need for users to do trial runs to create a classlist for each application.
 - Support both builtin class loaders and customized class loaders effectively and uniformly.

Dynamic archiving for a given application can done at the first execution of the application or when requested by users via command-line option, -XX:ArchiveClassesAtExit=<dynamic archive>. For example:

  % bin/java -XX:ArchiveClassesAtExit=<dynamic archive> -cp hello.jar HelloWorld

Currently, the command line option approach is being implemented.

* The dynamically genarated archive is created on top of the default system archive packaged with the running JDK binary. A separate top-layer archive file is generated for each different Java application. User can specify the application's archive name/path using the -XX:ArchiveClassesAtExit=<dynamic archive> option.

* If desired by user, the system archive can be ignored and all system classes (including the ones in the system archive) loaded during the application execution are archived into the dynamically created archive file. In that case, only one archive (the dynamic archive) is in effect. This behavior can be achieved via a new command-line option, and can be implemented after the initial integration.

* As the dynamically created top layer archive has dependency to the base archive (e.g. pointers to base layer data), the CRC values of the base archive header and all shared spaces are recorded in the top layer. At runtime, when the dynamic archive is mapped in, all recorded CRC values are compared with the currently mapped base archive CRC values. If any of the CRC value mismatches, the dynamic archive is disabled without affecting the use of the currently used base archive. Using CRC values for base archive dependency checking is more robust than the file name, size and timestamp checks.

* The memory lay-out in the top-layer dynamic archive is similar to the existing static archive that's created using a classlist. Metadata is separated into following three spaces. No 'md' or 'od' space needed.

 - rw space: Read-writable data
 - ro: Read-only data
 - mc: Trampoline

The shared spaced are mapped individually at runtime. The 'ro' space is mapped as read-only for sharing.

* Currently archiving (copying and relocating metadata) is done at the end of the application execution and before VM exiting. If a user defined class loader and associated classes are unloaded, those classes are not archived. Following is a solution for user defined class loaders that is planned after the initial integration:

Copying/relocating of the class metadata can be done immediately after loading a requested class (or before unloading).

* All loaded application classes and library classes (excluding the ones already included in the base layer and the ones that cannot be archived) are archived in the top-layer.

* Only class metadata is archived in the top layer currently. Archiving java heap objects in the top-layer dynamically requires more investigations and is not supported in initial implementation.

* Relocation of the archived java heap objects from the base layer (the default CDS archive) is done at dynamic archiving time, if the narrow oop encoding mode is different from the recoded mode in the base archive or if the archived heap regions are out of the current java heap range. As an optimization, the relocated java objects can be saved in the dynamic archive for subsequent use.