On Thu, 26 Sep 2024 00:49:20 GMT, Calvin Cheung <cche...@openjdk.org> wrote:
>> Prior to this patch, if `--module-path` is specified in the command line: >> during CDS dump time, full module graph will not be included in the CDS >> archive; >> during run time, full module graph will not be used. >> >> With this patch, the full module graph will be included in the CDS archive >> with the `--module-path` option. During run time, if the same >> `--module-path` option is specified, the archived module graph will be used. >> >> The checking of module paths between dump time and run time is more lenient >> compared with the checking of class paths; the ordering of the modules is >> unimportant, duplicate module names are ignored. >> E.g. the following is considered a match: >> dump time runtime >> m1,m2 m2,m1 >> m1,m2 m1,m2,m2 >> >> I included some >> [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) >> in the bug report regarding some changes in the corelib classes. > > Calvin Cheung has updated the pull request incrementally with one additional > commit since the last revision: > > @iklam comments src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java line 1095: > 1093: moduleToReader.clear(); > 1094: } > 1095: } Do you remember why resetArchivedStates resets the resource cache? I would expected it to be cleared for all class loaders. Rather than putting something specific to the app class loader here then maybe it should be renamed and have resetArchivedStates call it, e.g. void resetArchivedStates(boolean all) { ucp = null; resourceCache = null; if (all) { moduleToReader.clear(); } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1778453669
