JDK-8186842 : Use Java class loaders for creating the CDS archive
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2017-08-28
  • Updated: 2019-05-22
  • Resolved: 2017-08-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10
10 b23Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
This is the open version of the closed RFE JDK-8172218.

Up to JDK 9, we have been using the boot class loader to load all classes during CDS archive creation time. By switching to using Java class loader in JDK 10, we will make the CDS archive creation process more flexible for future enhancements.


Comments
Since we're using java class loaders during dumping, the preload_and_dump() needs to be moved to the end of Threads::create_vm() so that the vm is fully initialized and we are able to call java methods and able to make sure of the initialized module system. When using only the boot loader during dumping, we find the class loader type of a class from the ModuleLoaderMap.dat (part of the run time image). With this approach, the class loader type can be obtained from the instanceKlass upon its creation. Since java code is being run during dumping, more unshareable info needs to be removed. Such as: - calling SystemDictionary::clear_invoke_method_table() at the end of preload_and_dump() - updated ArrayKlass::remove_unshareble_info() (previously, the code that handles array class restoration was using instanceKlass::array_klasses_do, but this function doesn't apply to the 8 type array klasses (boolean[], byte[], etc.) - ConstantPool::remove_unshareable_info() - update unresolved class entry, also removesunshareable info for the ConstantPoolCache. - ConstantPoolCache::remove_unshareble_info() clean up ConstantPoolCache due to effect of linking from execution of Java code keep constant_pool_index() bits for all entries keep _f2 field for entries used by invokedynamic and invokehandle Added tracing of removal and restoring unshareable info (-Xlog:cds+unshareable=trace). Initially, this RFE will only support the --add-modules jigsaw option. Other jigsaw options will be addressed in subsequent RFE's. This RFE will not archive anonymous classes. They will be filtered out before writing into the archive. Notes on some of the modified files: =========================== templateTable_sparc.cpp The problem is invokevfinal depends on the value in the cpCache, but the cpCache's value depends on class resolution so it cannot be preserved in the archive. So when invokevfinal is executed, it gets a bad value from the cpCache and throws an exception, but at this point it's too early to load the exception classes so we end up in an infinite recursion. classLoader.cpp don't load any class from the app classpath, let the built-in app class loader load them record_shared_class_loader_type() new function classLoaderExt.cpp enhanced obtaining classloader_type - obtain the classloader_type based on the created InstanceKlass dictionary.cpp check for signed classes and exclude them from the archive because the certificates used during dump time may be different than those used during run time (due to expiration, etc.) klassFactory.cpp setup pathname (code source) calls ClassLoader::record_shared_class_loader_type() stringTable.cpp removed an assert; there's one in filemap.cpp systemDictionary.cpp clear_invoke_method_table() new function combine the dictionaries for boot/platform/app loaders into the boot loader dictionary since during run time we only have one shared dictionary. This is necessary after merging with 7133093 (Improve system dictionary performance and resizing) rewriter.cpp verify cpCache just initialized metaspaceClosure.hpp required changes after merging with 8072061 (Automatically determine optimal sizes for the CDS regions) to avoid an assert in ArchiveCompactor::allocate() metaspaceShared.cpp added array classes handling in CollectClassesClosure and remove_unshareable_in_classes() added remove_java_mirror_in_classes() - removal of java_mirror has been separated from remove_unshareble_in_classes() because in Dictionary::reorder_dictionary_for_sharing() it checks for signed classes which requires the java_mirror. arrayKlass.cpp updated remove_unshareable_info and restore_unshareable_info (The code that handles array class restoration was using instanceKlass::array_klasses_do, but this function doesn't apply to the 8 type array klasses (boolean[], byte[], char[], short[], int[], float[], long[], and double[]).) added remove_java_mirror() constantPool.cpp remove_unshareable_info - update unresolved class entry also remove_unshareable_info for the corresponding cpCache required changes after merging with 8179302: Pre-resolve constant pool string entries and cache resolved_reference arrays in CDS archive constantPoolCache.cpp added remove_unshareable_info, verify_just_initialized, reinitialize, walk_entries_for_initialization verify_just_initialized : make sure the _f2 field is 0 if it is not being used reinitialize : set _indices reset _f1, _flags, _f2 (if not being used) walk_entries_for_initialization : used by both verify_just_initialized and remove_unshareable_info - clean up ConstantPoolCache due to effect of linking from execution of Java code - keep constant_pool_index() bits for all entries - keep _f2 field for entries used by invokedynamic and invokehandle instanceKlass.cpp updated remove_unshareable_info and restore_unshareable_info for ArrayKlass handling klass.cpp added logging in remove_unshareable_info and restore_unshareable_info clearing of java_mirror is done separately - see metaspaceShared.cpp arguments.cpp the --add-modules option can be handled with this changes during dummp time, disable biased locking now as it interferes with the clean up of the archived Klasses and Java string objects exception.cpp adjusted some condition as we can throw expection during dumping
28-08-2017