Re: RFR: 8396375: JFR: JNI-attached threads are missed from CPU-time sampling

[Andrei Pangin]

On Mon, 2 Nov 2026 15:06:43 GMT, Andrei Pangin <apan...@openjdk.org> 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);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/33678#discussion_r4463210200