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