RFR: 8252689: Classes are loaded from jrt:/java.base even when CDS is used

[Ioi Lam]

On Fri, 11 Sep 2020 19:38:58 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> I think you could achieve the same if you extend the
> [HelloClasslist](https://github.com/openjdk/jdk/blob/master/make/jdk/src/classes/build/tools/classlist/HelloClasslist.java)
> tool built and used to generate the default classlist file to include a manifest in its jar file. Add a dummy
> manifest.mf somewhere and edit the CLASSLIST_JAR target in
> [GenerateLinkOptData](https://github.com/openjdk/jdk/blob/master/make/GenerateLinkOptData.gmk) to include it in the
> jar.  This would avoid hard-coding this in hotspot code and keep the responsibility of curating the default classlist
> in one place.

During the JDK build, HelloClasslist is already packaged with a manifest:

$ jar tf ./support/classlist.jar
META-INF/
META-INF/MANIFEST.MF
build/tools/classlist/HelloClasslist.class
And the default CDS archive contains the 3 classes mentioned in the bug report:
$ ./images/jdk/bin/java -cp ./support/classlist.jar -verbose build.tools.classlist.HelloClasslist | \
    egrep '((java.util.jar.Attributes)|(java.util.LinkedHashMap)|(java.util.jar.Manifest.FastInputStream)) source'
[0.044s][info][class,load] java.util.jar.Attributes source: shared objects file
[0.044s][info][class,load] java.util.LinkedHashMap source: shared objects file
[0.044s][info][class,load] java.util.jar.Manifest$FastInputStream source: shared objects file
However, for some reason, if you run a simple HelloWorld.jar to collect the class list, these 3 classes are not loaded.
As a result, these classes may not be stored in custom archives created from your own class lists. $ jar tf
~/tmp/HelloWorld.jar META-INF/
META-INF/MANIFEST.MF
HelloWorld.class
$ ./images/jdk/bin/java -Xshare:off -cp ~/tmp/HelloWorld.jar -verbose \
    -XX:DumpLoadedClassList=foo.list HelloWorld | egrep \
    '((java.util.jar.Attributes)|(java.util.LinkedHashMap)|(java.util.jar.Manifest.FastInputStream)) source' | wc
      0       0       0
I think the reason is the built-in class loader's Java code takes a different code path than the CDS shared class
loading code
([systemDictionaryShared.cpp](https://github.com/openjdk/jdk/blob/5c0d985abf7ef89f9a035692fe9db3ef4001bc2c/src/hotspot/share/classfile/systemDictionaryShared.cpp#L687)).
So we should exercise the CDS code during dump time to ensure that the classes used by CDS are always loaded.

-------------

PR: https://git.openjdk.java.net/jdk/pull/134