Preliminary code review for 8207812: Implement Dynamic Class Metadata Archive

[Jiangli Zhou]

Providing a mechanism for archiving class metadata as part of a Java 
application execution has been suggested & requested by many in the 
past. We have listened and this mechanism is now materialized. The 
following webrev is the implementation for dynamic archiving. It 
improves CDS/AppCDS usage by eliminating the need for trial runs. The 
implementation is contributed by Calvin, Ioi and myself. The code is 
still relatively raw and requires more testing (including test 
development), cleanup, and polish. We'd like to seek early feedback from 
the community with this preliminary code review.

   webrev: 
http://cr.openjdk.java.net/~jiangli/8207812_dynamic_archive/webrev.00/
   RFE: https://bugs.openjdk.java.net/browse/JDK-8207812


Description
=======

A shared archive for a given Java application is dynamically created at 
the application runtime when -Xshare:dynamicDump is enabled. The archive 
is created on top of the default CDS archive packaged with the running 
JDK binary. A separate top-layer archive file is generated for each 
different Java application. Users can specify the archive name&path 
using -XX:SharedDynamicArchiveFile=<path> option.

   Example: % bin/java -Xshare:dynamicDump 
-XX:SharedDynamicArchiveFile=hw.jsa -cp hello.jar HelloWorld

NOTE: the command-line options for dynamic archiving is not yet 
finalized. Please see JDK-8207812 comments for more details.

With the dynamic archive in place, following configurations are 
supported at runtime:

- Default CDS archive (base) + dynamic archive: when both archives are 
mapped successfully
- Base archive only: when dynamic archive cannot be mapped

If the base layer archive cannot be mapped and used at runtime, the top 
layer archive is automatically disabled.

Base Layer Dependency
--------------------
As the dynamically created top layer archive has dependency on the base 
archive (e.g. pointers to base layer data), the CRC checksums 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 
checksums are compared with the currently mapped base archive CRC 
values. If any of the CRC checksum mismatches, the dynamic archive is 
disabled without affecting the usage of the currently mapped base archive.

Copying and Relocating Class Metadata
---------------------------------
All loaded application classes and library classes (excluding the ones 
included in the base layer) are dynamically archived in the top-layer 
based on the current execution context. Copying and relocating of class 
metadata is done at the end of the application execution and before VM 
exit. Cleanup is done for archived data to remove any un-shareable 
information. If a user defined class loader and associated classes are 
unloaded, those classes are not archived in the currently 
implementation. Entrenchment for user defined class loader support will 
be added after initial integration.


Shared Spaces in Dynamic Archive
-----------------------------

The memory lay-out in the dynamic archive is similar to the existing 
static archive created using a classlist. Metadata is separated into 
following four spaces. No 'md' space is needed (C++ vtables are from the 
base archive). No archived Java heap regions are included in the dynamic 
archive currently.

  - rw space: Read-writable data
  - ro: Read-only data
  - mc: Trampoline
  - od: Optional data (class file data, for JVMTI support)

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

Preliminary performance data with HelloWorld indicates there is no 
observable runtime performance degradation with dynamic archive.

The change currently pass all tier1, tier2 and tier3.


Thanks,

Jiangli