On Mon, 4 Dec 2023 18:16:52 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. > > Daniel D. Daugherty has updated the pull request incrementally with one > additional commit since the last revision: > > dholmes CR - adjust a comment. We would need to examine all uses of JvmtiVMObjectAllocEventCollector::JvmtiVMObjectAllocEventCollector() to see if they can occur in the context of an attaching thread prior to allocation of the thread object. I suspect not because we allocate immediately after creating the JavaThread. The issue we hit here was events triggered by the execution of the Java code for the Thread constructor. It may be that we are just lucky that the same Java code doesn't lead to the VMObjectAlloc event though. ??? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16934#issuecomment-1839755493
