RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v10]

Leonid Mesnik lmesnik at openjdk.org
Thu Sep 18 04:52:32 UTC 2025


On Thu, 18 Sep 2025 04:42:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yes, the purpose 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.
>> 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) {`
>> 
>> 
>> And the value 'register_vthread_SR'  doesn't correlate with this method. It 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.
>> 
>> Hope it makes clearer.
>
> Thanks - though I find this code rather convoluted. We now always extract the `id` even though we only need it in the `register_vthread_SR == true` case. I tried different re-arrangements of the code to see if it could be cleaner, but the JVMTI part is just messy.

Yes, the id is always extracted and the exposure of "raw" id on this level is not the good desing. However, I don't know how to implement this better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2357508462


More information about the serviceability-dev mailing list