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.