RFR: 8364314: java_lang_Thread::get_thread_status fails assert(base != nullptr) failed: Invalid base [v2]

[David Holmes]

On Wed, 30 Jul 2025 22:56:47 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> David Holmes 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:
>> 
>>  - Remove from ProblemList
>>  - Merge branch 'master' into 8364314-threadSMR
>>  - 8364314: java_lang_Thread::get_thread_status fails assert(base != nullptr) failed: Invalid base
>
> I just finished catching up on this other issue/PR:
> 
> [JDK-8361103](https://bugs.openjdk.org/browse/JDK-8361103) java_lang_Thread::async_get_stack_trace does not properly protect JavaThread
> https://github.com/openjdk/jdk/pull/26119
> 
> And this comment from @sspitsyn stuck out to me w.r.t. to this fix:
> 
> https://github.com/openjdk/jdk/pull/26119#discussion_r2209135122
> 
> 
> But, please, note that the JvmtiVTMSTransitionDisabler mechanism is enabled
> only when there is a JVMTI agent. Otherwise, it has been disabled for scalability
> purposes to exclude potentially high performance overhead at the VTMS
> transition points.
> 
> 
> The above comment from Serguei calls into question this suggested change that I posted on the PR:
> 
> https://github.com/openjdk/jdk/pull/26544/files#r2243188114
> 
> If the JvmtiVTMSTransitionDisabler only works when there's an agent attached,
> I don't think we're protecting the carrier thread at all since it can become unmounted
> at anytime when there's no agent.

@dcubed-ojdk I had already examined all the other clients of `cv_internal_thread_to_javaThread` and determined that they did not involve virtual threads - as referenced in our internal discussions. Unfortunately I forgot to put a comment to that affect in the JBS issue. In any case those usages are not relevant to the current PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/26544#issuecomment-3148699030