JDK-8350422 : Support unwinding of native stack parts in JFR when last Java PC is not saved
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jfr
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2025-02-20
  • Updated: 2025-04-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
Description
When example program from JDK-8323755 is method-sampled by JFR it often samples the target java thread that calls currentTimeMillis(). But the PC actually belongs to a method from libc which may have debug information, and there is no last Java PC in the anchor in the sampled thread (the intrinsic is implemented as a leaf vm call, the PC is not saved). Such samples are discarded. This is not specific to linux/aarch64, the same happens other platforms.

https://github.com/openjdk/jdk/blob/c33c1cfe7349ac657cd7bf54861227709d3c8f1b/src/hotspot/share/jfr/periodic/sampling/jfrCallTrace.cpp#L107

Instead of that JFR could at least unwind the stack down to last Java frame, or try to construct the full stack including the external frames like other profilers do.
Comments
In its first incarnation, cooperative JFR sampling will not improve on sampling for intrinsics. However, the next stage in a multi-stage project suite of sampling-related projects, working title "Sampling Accuracy," will improve on sampling for intrinsics.
19-04-2025

There is ongoing work on cooperative sampling, hopefully ready for JDK 25, that will address intrinsics not being sampled.
21-02-2025