P4
Currently, JFR profiling is limited to Java code only. Providing visibility into C/C++/Rust frames is crucial for performance analysis of applications that use native libraries (Netty, OpenSSL, zstd, sqlite, LWJGL, RocksDB, TensorFlow, etc.) A typical example is a native library excessively calling malloc/free.
Even a pure Java program often spends much CPU time inside JDK native libraries or standard OS libraries. To help developers troubleshoot performance issues beyond their Java code, we will extend CPUTimeSample event with information about native part of a stack trace.
To keep implementation simple, localized and risk-free, we accept the following limitations:
1. Walk only topmost native frames, i.e. those above the first Java frame. Native frames in the middle of the stack are rarely useful, but supporting them would complicate the architecture.
2. No in-process symbolication. JFR recording will contain PC addresses only. External tools will resolve symbols separately with the help of jdk.NativeLibrary events.
3. Unwind stack by frame pointer chasing. This is fast, safe and simple. FP unwinding generally works on AArch64 and those Linux x86 distros that have frame pointers enabled by default (e.g. Ubuntu 24.04+, Fedora 38+). JDK itself is also typically compiled with -fno-omit-frame-pointer.
Proposed JFR changes:
- New `jdk.NativeStackFrame` type with is a single 64-bit `pc` field.
- New `jdk.NativeStackTrace` type containing an array of `jdk.NativeStackFrame`.
- Add `nativeStackTrace` field to `jdk.CPUTimeSample` event.
- Existing `jdk.StackTrace` type will remain intact.
Even a pure Java program often spends much CPU time inside JDK native libraries or standard OS libraries. To help developers troubleshoot performance issues beyond their Java code, we will extend CPUTimeSample event with information about native part of a stack trace.
To keep implementation simple, localized and risk-free, we accept the following limitations:
1. Walk only topmost native frames, i.e. those above the first Java frame. Native frames in the middle of the stack are rarely useful, but supporting them would complicate the architecture.
2. No in-process symbolication. JFR recording will contain PC addresses only. External tools will resolve symbols separately with the help of jdk.NativeLibrary events.
3. Unwind stack by frame pointer chasing. This is fast, safe and simple. FP unwinding generally works on AArch64 and those Linux x86 distros that have frame pointers enabled by default (e.g. Ubuntu 24.04+, Fedora 38+). JDK itself is also typically compiled with -fno-omit-frame-pointer.
Proposed JFR changes:
- New `jdk.NativeStackFrame` type with is a single 64-bit `pc` field.
- New `jdk.NativeStackTrace` type containing an array of `jdk.NativeStackFrame`.
- Add `nativeStackTrace` field to `jdk.CPUTimeSample` event.
- Existing `jdk.StackTrace` type will remain intact.