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). [First](https://github.com/openjdk/jdk/blob/9b9863e792ac6ae424c4f829d30cb5db90f01d61/src/hotspot/share/runtime/thread.cpp#L230), shared between Java and non-Java threads, called in `_thread_new` state. [Second](https://github.com/openjdk/jdk/blob/9b9863e792ac6ae424c4f829d30cb5db90f01d61/src/hotspot/share/runtime/javaThread.cpp#L628), specific to Java threads, called in `_thread_in_vm` state. The second one was added in https://github.com/openjdk/jdk/pull/26558, and `JfrThreadLocal::on_start` got state-dependent logic. ------------- PR Comment: https://git.openjdk.org/jdk/pull/33678#issuecomment-6593439645
