Implements the native profiler hook for unbiased stack-traces, as described in 
[JEP draft: Native Profiler Hook for Unbiased Stack Traces 
(Experimental)](https://openjdk.org/jeps/8380294).

New JVMTI extension functions:
- `EnableRequestStackTrace(jvmtiEnv*)` / `DisableRequestStackTrace(jvmtiEnv*)` 
- set up / tear down the stack-walker infrastructure. Setup is non-trivial 
(queues, deque lock, native stack-walker thread), so it cannot be done lazily 
inside the signal-safe request path. Only one agent at a time may enable this; 
subsequent calls return `JVMTI_ERROR_NOT_AVAILABLE`.
- `RequestStackTrace(jvmtiEnv*, jthread*, void* ucontext, jlong user_data)` - 
async-signal-safe request for a stack trace. For the current thread, `ucontext` 
may be `NULL` or the signal-handler `ucontext`. For another thread, the thread 
must be suspended for the duration of the call and ucontext must be captured 
during that suspension; otherwise the VM may crash. Returns `JVMTI_ERROR_NONE`, 
`JVMTI_ERROR_INVALID_THREAD`, or `JVMTI_ERROR_NOT_AVAILABLE`. Requests may be 
silently dropped (queue full, wrong thread state, rate-limited).

New experimental JFR event `StackTraceRequest` with fields `stackTrace`, 
`eventThread`, `userData`, `failed`, `biased`. Enabled in `profile.jfc`, not in 
`default.jfc` (the rate is controlled by the external agent, so default-on 
would expose users to unbounded overhead).

Refactoring: The stack-walker request machinery from JEP 509 (CPU-time 
profiler) is generalized into a callback-based API (`JfrStackWalkerCallback`) 
used by both the CPU-time profiler and the new JVMTI hook. Shared pieces: the 
per-thread signal-safe request queue, the enqueue/dequeue lock state machine, 
and the native stack-walker thread that processes requests for in-native 
threads. Two callback implementations remain: one for CPUTimeSample/empty/lost 
events, one for StackTraceRequest.

Non-goals (per the JEP): Native frames are not reported; this is a follow-up.

Platform support: Linux and MacOS, or more generally POSIX. Windows support can 
be a follow-up, if ucontext is interpreted as WPA context.

Testing:
 - [x] jdk_jfr
 - [x] serviceability/jvmti

---------
- [x] I confirm that I make this contribution in accordance with the [OpenJDK 
Interim AI Policy](https://openjdk.org/legal/ai).

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into JDK-8383923
 - Replace NULL with nullptr
 - Merge branch 'master' into JDK-8383924
 - Add test for virtual thread support
 - Fix test
 - Rename RequestStackTrace to RequestJFRStackTrace
 - Better/clearer vthread support
 - Set default rate to 10ms
 - Implement support for non-current threads
 - Add tests
 - ... and 3 more: https://git.openjdk.org/jdk/compare/057985b5...69d1f962

Changes: https://git.openjdk.org/jdk/pull/31059/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=31059&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8383923
  Stats: 3917 lines in 46 files changed: 3382 ins; 490 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/31059.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/31059/head:pull/31059

PR: https://git.openjdk.org/jdk/pull/31059

Reply via email to