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). ------------- Commit messages: - 8396375: JFR: JNI-attached threads are missed from CPU-time sampling Changes: https://git.openjdk.org/jdk/pull/33678/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=33678&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8396375 Stats: 153 lines in 4 files changed: 152 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/33678.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/33678/head:pull/33678 PR: https://git.openjdk.org/jdk/pull/33678
