On Mon, 19 Oct 2026 22:58:59 GMT, Xin Liu <[email protected]> wrote: >> Andrei Pangin has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Added FlightRecorderOption to configure maximum native stack depth > > src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 613: > >> 611: >> 612: u4 count = 0; >> 613: while (count < max_frames) { > > Hi, @apangin > Even though 128 is very generous, I think it's still possible that we see a > deeper native traces. In other words, there're more than max_frames before > LJF. > > Current implementation just truncates silently. Do we need to emit a warning > message or an error code to remind end-users? or they have to realize that > from flamegraph.
Well, there are as many opinions as there are people. While [one feedback](https://github.com/openjdk/jdk/pull/32524#discussion_r3958462315) suggests that 8 frames should be sufficient, another says that 128 may not be enough. 128 was my conscious choice for multiple reasons: - From my experience of async-profiling, I don't recall seeing native stacks deeper than that in _Java_ applications, except for cases when stack walking was broken. Deep recursion in native code is of course possible, but getting full stack traces in such edge cases adds little value and is not practical. - We can't really use much more than 1KB (128*8) of stack inside a signal handler safely. - Linux's own perf stack depth (kernel.perf_event_max_stack) is capped by 127 by default. Printing a warning is not permitted inside a signal handler. JFR does not print anything today wihen it truncates Java stack traces, and its existing `truncated` flag (which is about reaching root frame) does not fit our use case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32524#discussion_r4321128468
