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