On Tue, 20 Oct 2026 03:20:48 GMT, Andrei Pangin <[email protected]> wrote:
>> 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.
okay. I forget we can't emit anything inside of a signal handler. it's okay to
me that we truncate here.
Can we leave a comment here? just say the truncation is by design.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32524#discussion_r4331326450
