RFR: 8168797: do not load any archived classes from a patched module
ioi.lam at oracle.com
Fri Dec 9 05:36:52 UTC 2016
The changes look good. Just a small nit in classLoader.cpp:
1452 // class is still loaded from the [jimage|exploded build] even
if it might
"exploded build" should be removed, because CDS is not supported in
$ jdk/bin/java -Xshare:dump
Error: non-empty directory '/jdk/bld/ul/jdk/modules/java.base'
On 12/8/16 6:22 PM, Jiangli Zhou wrote:
> Please review the following CDS changes for supporting jigsaw —patch-module.
> bug: JDK-8168797 <https://bugs.openjdk.java.net/browse/JDK-8168797>
> http://cr.openjdk.java.net/~jiangli/8168797/webrev.00/ <http://cr.openjdk.java.net/~jiangli/8168797/webrev.00/>
> Before the change, CDS requires strict matching of the dump time and runtime —patch-module entries. If the runtime entries are different from the dump time, the shared archive cannot be used. Also, directories in the entries were not allowed.
> With the above changes, the shared archive can still be used if the runtime —patch-module differs from the dump time’s. Changing of the —patch-module option does not invalid the entire shared archive. Additional runtime shared class visibility check is added to ensure the VM does not load any archived class if the belonging module is patched, based on the runtime setting. Archived classes from un-patched module can still be loaded and used. When java.base module is patched at runtime, sharing is disabled since none of the archived classes can be loaded. The shared String objects can not be used in that case either.
> As part of the changes, old code that requires the matching of runtime & dump time —patch-module is removed.
> Tested with JPRT, related tests via RBT.
More information about the hotspot-runtime-dev