On Mon, 2 Nov 2026 15:06:43 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). Not sure where the "twice per Java thread" is coming from? AFAICS regular Java threads call it from run() and attached threads call it when they attach. My point was that: if (jt->thread_state() == _thread_new) { JfrCPUTimeThreadSampling::on_javathread_create(jt); } else { is unreachable code because we've already switched to `_thread_in_vm` on both paths. And whichever path we followed we should be calling `JfrCPUTimeThreadSampling::on_javathread_create`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/33678#issuecomment-6593096788
