This is an umbrella RFE designed to harvest the benefit of CDS archiving by default and improve its usability. The umbrella RFE contains several sub-tasks/RFEs, which can be implemented independently. The completion of the individual sub-tasks can be targeted for different upcoming JDK releases.

The hybrid approach combines a two-layer archiving and static & dynamic archiving techniques:

- Statically archive system library classes from a provided classlist using the existing method. The archiving includes class metadata, interned string objects, constant pool resolved_references arrays, class mirror objects, etc. Static archiving can be done at the JDK image build time and shipped together with JDK binary. Following need to be addressed:
       *Relaxing the runtime CDS/AppCDS boot path check, so the packaged archive can be used after the JDK binary is installed on the target device. JDK-8199807 has been created to address this issue.
       *Add the static archiving generation in JDK build steps and package the generated archive with JDK image. The archive can only be generated for the same target (both OS can CPU architecture) as the build platform. 

- Dynamic archiving can done for application classes at the first execution of a specific application or when requested by users via command-line option (JDK-8207812)
       * The archive is created on top of the default system archive shipped with the JDK image. A separate top-layer archive file is generated for each different application. 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.
       * Archiving (relocating metadata to the archiving spaces) is done at the end of the application execution before VM exists by relocating the class metadata to the archive spaces. Cleanup also needs to be done for copied class meta data to remove any runtime information.
       * All loaded application classes, middleware classes and system library classes (excluding the ones included in the bottom layer) are archived in the top-layer.
       * Only archive class metadata in the top layer initially. Archiving java heap objects in the top-layer requires more investigations.
       * If archived java objects from the base archive cannot be mapped due to the specific settings (java heap size, etc) required by the application, relocate the archived java objects as part of the dynamic archiving process:
            + If the current narrow oop encoding or narrow klass encoding is different from the archived encodings, update all pointers within the archived objects.
            + If the address locations (computed from archived data, which could be different from the archived region addresses at dump time) of the archived java heap regions are out of the current java heap range, allocate new GC regions from the current java heap and map the archived objects into the allocated regions. Update all pointers in the mapped objects.

Benefits of the hybrid archiving:
* The system archive can be shared by different applications and provides memory saving.
* Archive for application is created and used transparently. No more profiling step and class list are required!
* Separating the system archiving from application archiving reduces the cost of archiving at application execution time. The overhead added to the first execution time is reduced.
* Relocation of the archived java objects are done at the top-layer archiving time. No overhead is introduced to runtime. 'Read-only' java objects can still be shared by different JVM processes running the same application if archived java object relocation happens. 
* Archived java objects from the based archive can be utilized for startup/memory benefits even when an application requires different GC ergonomics.