RFR: 8168797: do not load any archived classes from a patched module
jiangli.zhou at oracle.com
Mon Dec 12 20:18:45 UTC 2016
> On Dec 12, 2016, at 9:58 AM, Calvin Cheung <calvin.cheung at oracle.com> wrote:
> Hi Jiangli,
> The changes look good other than the incorrect comment in classLoader.cpp as pointed out by Ioi.
> 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>
>> 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