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

Aleksey Shipilev shade at openjdk.org
Wed Apr 23 11:32:10 UTC 2025


On Mon, 31 Mar 2025 23:40:09 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Shared utility class for method unload blocking
>>  - Merge branch 'master' into JDK-8231269-compile-task-weaks
>>  - JNIHandles -> VM(Weak)
>
> src/hotspot/share/runtime/methodUnloadBlocker.inline.hpp line 72:
> 
>> 70:   assert(!is_unloaded(), "Pre-condition: should not be unloaded");
>> 71: 
>> 72:   if (!_weak_handle.is_empty()) {
> 
> Does the precondition imply that `!_weak_handle.is_empty()` always hold?

Not really. The precondition is:


 !is_unloaded() -> 
 !(!_weak_handle.is_empty() && _weak_handle.peek() == nullptr) -> 
 (_weak_handle.is_empty() || _weak_handle.peek() != nullptr)


So you see, there is a case when weak handle is empty. It is when `_method` is `nullptr` (default initialized, no method is set), or its unload blocker is `nullptr` (method would be unloaded). Then we bypass the majority of weak->strong dance as unnecessary.

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

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


More information about the hotspot-gc-dev mailing list