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

[Jiangli Zhou]

On Mon, 13 Nov 2023 23:04:19 GMT, Man Cao <manc at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Don't try to setup_jvmti_thread_state for obj allocation sampling if the current thread is attaching from native and is allocating the thread oop. That's to make sure we don't create a 'partial' JvmtiThreadState.
>
> src/hotspot/share/prims/jvmtiThreadState.inline.hpp line 94:
> 
>> 92:   // The state->get_thread_oop() may be null if the state is created during
>> 93:   // the allocation of the thread oop when a native thread is attaching. Make
>> 94:   // sure we don't create a new state for the JavaThread.
> 
> I think it is important to maintain `JvmtiThreadState::_thread_oop_h` correctly for the attached native thread. In the existing logic, with and without the proposed change, `JvmtiThreadState::_thread_oop_h` could stay null for an attached native thread, which seems wrong.
> 
> It may be OK since `JvmtiThreadState::_thread_oop_h` is only used by support for virtual threads. It is unlikely that an attached native thread becomes a carrier for a virtual thread. However, it is probably still desirable to update `JvmtiThreadState::_thread_oop_h` to the correct java.lang.Thread oop.

Thanks for the input @caoman. I updated the PR to avoid creating a JvmtiThreadState during attaching and allocating thread oop. I think that avoids a incomplete JvmtiThreadState being created, which is seems to be cleaner.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16642#discussion_r1393334558