RFR: 8231269: CompileTask::is_unloaded is slow due to JNIHandles type checks [v6]

Vladimir Ivanov vlivanov at openjdk.org
Mon Apr 28 18:51:48 UTC 2025


On Mon, 28 Apr 2025 16:16:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I remember looking at this, and convinced myself that non-strong hidden classes report their related Java mirror as `klass_holder`, and that is enough to maintain them as alive. See calls to `ClassLoaderData::initialize_holder`:
>> 
>> https://github.com/openjdk/jdk/blob/b1e778d9d2ad13ee5f1ed629a8805008580f86c0/src/hotspot/share/classfile/classLoaderData.cpp#L159-L162
>> 
>> https://github.com/openjdk/jdk/blob/b1e778d9d2ad13ee5f1ed629a8805008580f86c0/src/hotspot/share/classfile/systemDictionary.cpp#L810-L814
>> 
>> This is what the comment in `UnloadableMethodHandle::get_unload_blocker` refers to. So I believe current code is correct. 
>> 
>> I agree `is_permanent_class_loader_data()` captures the intent better. Let me see if it fits well here.
>
>> I agree is_permanent_class_loader_data() captures the intent better. Let me see if it fits well here.
> 
> Ah wait, it does not. We need to hold on to something that blocks the unloading. Just checking `is_permanent_class_loader_data()` does not get us there. We would need to ask for some holder for it. For the reasons above, `method->method_holder()->klass_holder()` works for non-strong hidden classes as well.
> 
> This is also why current mainline code works -- it captures the same thing.

Ok, thanks for checking! Good to know there's no existing bug.

What I had in mind is as follows:

InstanceKlass* holder = method->method_holder();
if (holder->class_loader_data()->is_permanent_class_loader_data()) {
  return nullptr; // method holder class can't be unloaded
} else {
  // Normal class, return the holder that would block unloading.
  // This would be either classloader oop for non-hidden classes,
  // or Java mirror oop for hidden classes.
  assert(holder->klass_holder() != nullptr, "");
  return holder->klass_holder();
}


IMO it makes the check more precise and, at the same time, communicates the intent better. What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24018#discussion_r2064315717


More information about the hotspot-compiler-dev mailing list