RFR: 8310874: Runthese30m crashes with klass should be in the placeholders during verification [v3]

Coleen Phillimore coleenp at openjdk.org
Wed Sep 20 21:59:43 UTC 2023


On Fri, 15 Sep 2023 03:15:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Right.  The constraint is added when we are checking the class signatures (check_signature_loaders) - we add the constraint as class name and the class loader.  When the class is loaded in SystemDictionary::check_constraints, we add the InstanceKlass that was loaded in the loader constraint entry for the name.
>> Further checks are make sure that the klass in the constraint is the same as the class currently being loaded, ie: 
>> 
>>         ss.print("loader constraint violation: loader %s", loader_data->loader_name_and_id());
>>         ss.print(" wants to load %s %s.",
>>                  k->external_kind(), k->external_name());
>>         Klass *existing_klass = LoaderConstraintTable::find_constrained_klass(name, loader_data);
>>         if (existing_klass != nullptr && existing_klass->class_loader_data() != loader_data) {
>>           ss.print(" A different %s with the same name was previously loaded by %s. (%s)",
>> 
>> 
>> Ioi wanted me to add a comment that this isn't a leak.  It's not.  This constraint (name, loader) is valid as long as the class loader is loaded.  It is removed when the class loader unloads in SystemDictionary::do_unloading.
>
> I don't understand what nulling out the klass actually achieves. ?? It seems to me to be allowing for a future attempt to re-load the same named class in the same loader, but IIRC that should not be allowed - at least in terms of resolution errors.

If the class loading fails for Klass and we delete Klass, we don't want a dangling pointer to Klass anywhere.  There are other mechanisms to prevent class loading for resolution errors.  This may allow retrying for OOM, which this the path that this case may allow.  But the point is to not have dangling pointers in the LoaderConstraintTable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15752#discussion_r1327193769


More information about the hotspot-runtime-dev mailing list