On Wed, 4 Nov 2026 03:23:09 GMT, Andrei Pangin <[email protected]> wrote:
>> A change in JDK-8364258 broke CPU-time sampling for threads that call JNI >> `AttachCurrentThread` or `AttachCurrentThreadAsDaemon` while profiler is >> active. This PR restores the correct behavior, allowing JNI-attached threads >> to be sampled, whether they attach before or after enabling profiler. >> >> When a native thread is attached to the JVM, it goes directly to >> `_thread_in_vm` state, but `JfrThreadLocal::on_start` enables CPU-time >> sampling only for `_thread_new` threads. The fix is to add an explicit check >> for `is_attaching_via_jni()`. >> >> Testing: all `jdk_jfr` tests, including new `TestCPUTimeSamplingJNIAttach`. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 154: > >> 152: // A thread attaching via JNI does not go through _thread_new >> state >> 153: JfrCPUTimeThreadSampling::on_javathread_create(jt); >> 154: } > > Alternative fix: > > if (jt->thread_state() == _thread_new) { > return; > } > assert(jt->thread_state() == _thread_in_vm, "invariant"); > JfrCPUTimeThreadSampling::on_javathread_create(jt); Can the sampler issue a an interrupt while the thread is still in _thread_new? You are safe anyway, because the thread has already been assigned an id. But if you are not sampling _thread_new states, then the alternative fix makes sense. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/33678#discussion_r4466815406
