On Mon, 13 Nov 2023 23:04:19 GMT, Man Cao <m...@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
