RFR(S) 8193332 MetaspaceShared::check_shared_class_loader_type is not used during archive creation

[Jiangli Zhou]

Hi Ioi,

- classLoader.cpp
I think the change in ClassLoader::load_class() is ok. We used to support --limit-modules at CDS runtime. So an archived ‘module’ classes from the -Xbootclasspath/a could be used at runtime. That’s the reason why we wanted to make the archived classes as a superset of all runtime loadable classes. In JDK 11, we’ve eliminated the support of --limit-modules from CDS because --limit-modules is only useful for testing mode and it complicates CDS code unnecessary. It’s good that the special case for DumpSharedSpaces in general class loading code is gone.

- metaspaceShared.cpp
The changes look ok. I also want to note that the loader_type records in archived classes is no longer necessary. The loader type  of archived classes including for user defined class loaders can be quickly determined by the shared path indexes. Eliminating the loader type for archived classes will help to clean up the code further and also free 3 bits in InstanceKlass _misc_flags for other usage. I’ll file a RFE for loader type cleanups.

All the rest of the changes also look good to me.

Thanks,
Jiangli

> On May 17, 2018, at 6:13 PM, Ioi Lam <ioi.lam at oracle.com> wrote:
> 
> https://bugs.openjdk.java.net/browse/JDK-8193332
> http://cr.openjdk.java.net/~iklam/jdk11/8193332-check_shared_class_loader_type.v01/
> 
> Summary:
> 
> When we restructured the AppCDS code, the call to MetaspaceShared::check_shared_class_loader_type
> was somehow left out. I have restored it, and actually found a minor bug related to modules
> and -Xbootclasspath/a:
> 
> In classLoader.cpp, at dump time we used to load a class from -Xbootclasspath/a even if
> this class belongs to a named packaged, which means it would not be loaded by the JVM at runtime.
> Such dump-time loading seems unnecessary so I removed it, and fixed a related test case
> to reflect the latest behavior.
> 
> Tested with hs-tier1,2.
> 
> Thanks
> - Ioi