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

[Aleksey Shipilev]

On Thu, 24 Apr 2025 00:36:18 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Allow UMH::_method access from VMStructs
>
> src/hotspot/share/runtime/unloadableMethodHandle.hpp line 43:
> 
>> 41: //  3. Final released state. Relevant Method* is in unknown state, and cannot be
>> 42: //     accessed.
>> 43: //
> 
> Please, elaborate what state transitions are supported. Currently, my understanding is there are 3 transitions and 4 states:
> * 1 -> 2
> * 2 -> 3 (terminal)
> * 1 -> 3 (terminal)
> * 0 (empty, terminal)

I added class-level docs for this handle, see if it reads well?

> src/hotspot/share/runtime/unloadableMethodHandle.inline.hpp line 57:
> 
>> 55: 
>> 56:   // Null holder, the relevant class would not be unloaded.
>> 57:   return nullptr;
> 
> Is this the case of bootstrap classloader? As an optimization opportunity, it can be extended for other system loaders.

Yes, this is about null (bootstrap) classloader; the system returns `nullptr` in this case. I don't think `UMH` gets to decide whether `!nullptr` holder is always alive or not, and it is safer to hold on to it.

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

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