JDK-8203447 : Clean up CDS archived class loader_type()
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9,10,11
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • Submitted: 2018-05-18
  • Updated: 2020-06-23
  • Resolved: 2020-06-23
Related Reports
Relates :  
JDK-8198698 - Support Lambda proxy classes in dynamic CDS archive
Description
The use of loader_type() for archived class can be cleaned up. An archived class' (including class for user defined class loader) loader type can be quickly determined using the shared path table index. Removing the loader_type misc flags and set_class_loader_type() will help eliminate duplication and make the code cleaner. It will also free 3 bits in InstanceKlass _misc_flags for other potential usages.
Comments
InstanceKlass _misc_flags bits in consideration: _misc_is_shared_boot_class = 1 << 12, // defining class loader is boot class loader _misc_is_shared_platform_class = 1 << 13, // defining class loader is platform class loader _misc_is_shared_app_class = 1 << 14, // defining class loader is app class loader Currently, the above bits are set in DynamicArchiveBuilder::make_klasses_shareable(). As mentioned above, JDK-8198698 also needs to set them. Some ideas: 1. We can potentially save one bit - we can set both bits 12 and 13 to indicate that it is a shared app class. 2. For JDK-8198698, we can use negative values of _shared_class_path_index to indicate that you have a lambda class for boot/platform/app loaders. e.g. -2 for boot, -3 for platform, etc. 3. We still need to know the loader type for other archived classes. Using the shared path table index (as suggested in the description) may not be sufficient as we now have module path index in the shared path table.
22-01-2020
Ok, thanks for the heads up.
24-05-2018
Please don't remove InstanceKlass::loader_type() yet. I may need it for CDS Lamda support.
24-05-2018