On Mon, 17 Jul 2023 16:55:03 GMT, Ioi Lam <ik...@openjdk.org> wrote:
>> Currently we exit the VM after static dumping with
>> `MetaspaceShared::exit_after_static_dump()`.
>>
>>
>> // We have finished dumping the static archive. At this point, there may be
>> pending VM
>> // operations. We have changed some global states (such as
>> vmClasses::_klasses) that
>> // may cause these VM operations to fail. For safety, forget these
>> operations and
>> // exit the VM directly.
>> void MetaspaceShared::exit_after_static_dump() {
>> os::_exit(0);
>> }
>>
>>
>> As the comment suggests, the VM state is altered when preparing and
>> performing the static dump, so this change aims to prevent these state
>> changes so the VM can exit normally after the static dump completes. There
>> are three major aspects to this change:
>> 1. Since the resolved references array in the Constant Pool is altered when
>> preparing for a static dump, a "scratch copy" is created and archived
>> instead
>> 2. Symbols are sorted by address and have their hash recalculated. Similarly
>> to point 1, the copies of the symbols that are to be archived have their
>> hashes updated as opposed to the originals.
>> 3. The handling of -Xshare:dump during argument parsing such that the VM can
>> continue and exit normally with an exit code of 0.
>
> src/hotspot/share/classfile/classLoaderData.cpp line 1085:
>
>> 1083: guarantee(this == class_loader_data(cl) ||
>> has_class_mirror_holder(), "Must be the same");
>> 1084: guarantee(cl != nullptr || this ==
>> ClassLoaderData::the_null_class_loader_data() || has_class_mirror_holder(),
>> "must be");
>> 1085: }
>
> Why is this necessary?
This seems to be a band-aid solution to a deeper problem: the java platform and
system loaders are reset. I believe the correct solution is to restore these
values after dumping completes
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1272766119
