RFR: 8319935: Ensure only one JvmtiThreadState is created for one JavaThread associated with attached native thread [v5]

[Daniel D. Daugherty]

On Wed, 22 Nov 2023 22:40:20 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review JvmtiThreadState::state_for_while_locked change to handle the state->get_thread_oop() null case. Please see https://bugs.openjdk.org/browse/JDK-8319935 for details.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address Serguei Spitsyn's comments/suggestions:
>   - Remove the redundant thread->is_Java_thread() check from JvmtiSampledObjectAllocEventCollector::object_alloc_is_safe_to_sample().
>   - Change the assert in JvmtiThreadState::state_for_while_locked to avoid #ifdef ASSERT.

A belated thumbs up. Sorry I didn't get back to this review
before the fix was integrated.

I found just a nit comment that could be more clear.

src/hotspot/share/prims/jvmtiExport.cpp line 3143:

> 3141: 
> 3142:   // If the current thread is attaching from native and its Java thread object
> 3143:   // is being allocated, things are not ready for allocation sampling.

nit - typo: s/is being allocated/has not been allocated/

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

PR Review: https://git.openjdk.org/jdk/pull/16642#pullrequestreview-1756369261
PR Review Comment: https://git.openjdk.org/jdk/pull/16642#discussion_r1409970009