RFR: 8319935: Ensure only one JvmtiThreadState is create for one JavaThread associated with attached native thread
Jiangli Zhou
jiangli at openjdk.org
Tue Nov 14 20:24:27 UTC 2023
On Tue, 14 Nov 2023 03:10:20 GMT, David Holmes <dholmes at openjdk.org> wrote:
> Is this a case where the code should be checking for `is_attaching_via_jni()`?
That's a good question. I think maybe we should try to completely avoid the situation where a 'partial' `JvmtiThreadState` is created when a native thread is attaching and is in the middle of allocating the thread oop. Looking at `JvmtiSampledObjectAllocEventCollector::start()`, I think we can check if the current JavaThread `is_attaching_via_jni()` and the `threadObj()` is null. If that's the case, don't try `setup_jvmti_thread_state()` as things are not ready. In `JvmtiThreadState::state_for_while_locked` we probably want to assert that thread->threadObj() is not null if thread->jvmti_thread_state() not null, to make sure that we don't see a incomplete `JvmtiThreadState`. @caoman, I think this can also address your input on keeping `JvmtiThreadState::_thread_oop_h` always properly initialized for the attaching native thread.
I tested it and it seems to work well. I'll update this PR.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/16642#issuecomment-1811187153
More information about the serviceability-dev
mailing list