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