On Sat, 2 Dec 2023 17:15:57 GMT, Daniel D. Daugherty <dcu...@openjdk.org> wrote:
> In the fix for the following bug: > > [JDK-8319935](https://bugs.openjdk.org/browse/JDK-8319935) Ensure only one > JvmtiThreadState is created for one JavaThread associated with attached > native thread > > JvmtiThreadState::state_for_while_locked() was changed to > return nullptr for attaching JNI threads regardless of whether > that JNI thread/JavaThread had a java.lang.Thread object. > > We should only filter out a JavaThread that's attaching via JNI > if it has no java.lang.Thread object. > > This fix has been tested with Mach5 Tier[1-7] and there are no related test > failures. > Mach5 Tier8 is in process. > > I'm going to need @jianglizhou to rerun her testing for: > > [JDK-8319935](https://bugs.openjdk.org/browse/JDK-8319935) Ensure only one > JvmtiThreadState is created for one JavaThread associated with attached > native thread > > since the test(s) for that fix are not yet integrated in the jdk/jdk repo. Initially I thought this was not the right fix as we should not be exposing an attaching thread that may still have a partially constructed `threadObj`. But this issue shows that we must expose such a thread because the constructor of the `Thread` object can trigger these events on the current thread so it must have a valid JVMTI state! Thanks. src/hotspot/share/prims/jvmtiThreadState.inline.hpp line 90: > 88: // Don't add a JvmtiThreadState to a thread that is exiting or is > attaching. > 89: // When a thread is attaching, it may not have a Java level thread > object > 90: // created yet. The comment needs adjusting now - suggestion: // Don't add a JvmtiThreadState to a thread that is exiting, or is attaching // and does not yet have a Java level thread object allocated. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16934#pullrequestreview-1761678171 PR Review Comment: https://git.openjdk.org/jdk/pull/16934#discussion_r1413421607
