On Mon, 14 Jul 2025 23:42:03 GMT, Leonid Mesnik <lmes...@openjdk.org> wrote:
> The problem happens if post_early_vm_start is triggered.
> The fix is to complete initialization once threadObj become available.
>
> I'vent observed that recompute_enable and hitting assertion might happens
> before this step. However it might be makes sense to check state in assertion
> if needed.
This looks good in general. Thank you for catching with Kitchensink and fixing
this issue!
I've posted a couple of nits.
src/hotspot/share/prims/jvmtiThreadState.cpp line 1046:
> 1044: void JvmtiThreadState::update_thread_oop_during_vm_start(JavaThread*
> thread) {
> 1045: assert(thread->threadObj() != nullptr, "santity check");
> 1046: if (thread->jvmti_thread_state()->get_thread_oop() == nullptr) {
Nit: Replace `thread->jvmti_thread_state()->get_thread_oop()` with
`get_thread_oop()`.
src/hotspot/share/prims/jvmtiThreadState.cpp line 1047:
> 1045: assert(thread->threadObj() != nullptr, "santity check");
> 1046: if (thread->jvmti_thread_state()->get_thread_oop() == nullptr) {
> 1047: _thread_oop_h.release(JvmtiExport::jvmti_oop_storage());
Nit: This line needs a comment explaining we are releasing an `OopHandle`
pointing to `null`.
-------------
PR Review: https://git.openjdk.org/jdk/pull/26303#pullrequestreview-3019013676
PR Review Comment: https://git.openjdk.org/jdk/pull/26303#discussion_r2206621244
PR Review Comment: https://git.openjdk.org/jdk/pull/26303#discussion_r2206627052
