RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v10]
Leonid Mesnik
lmesnik at openjdk.org
Thu Sep 18 03:15:47 UTC 2025
On Thu, 18 Sep 2025 02:45:46 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>>
>> renamed method
>
> src/hotspot/share/runtime/suspendResumeManager.cpp line 84:
>
>> 82: }
>> 83:
>> 84: void SuspendResumeManager::set_suspended_current_thread(int64_t vthread_id, bool register_vthread_SR) {
>
> It was totally not at all apparent that `_target` had to be the current thread here! Is it always the current thread? Won't this variant only ever get called when `register_vthread_SR` would be true - in which case we don't need that parameter?
The `set_suspended_current_thread` is called after check
` if (_target == self) {` in `void SuspendResumeManager::set_suspended_current_thread(int64_t vthread_id, bool register_vthread_SR) {`
The goal of this specialized method is to "pre-load"`thread_id = _target->vthread()` before current thread became blocked. It is not planned to use this method for any other purpose.
And the value 'register_vthread_SR' depends on which jvmti method is used :
- true for SuspenAllVirutalThrreads
- false for SuspendThread/SuspendThreadList
In both cases we can try to suspend current thread. So this method is called in both cases, even thread_id is really used only for SuspenAllVirutalThrreads.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2357403213
More information about the serviceability-dev
mailing list