search

oracle / graal

GraalVM compiles Java applications into native executables that start instantly, scale fast, and use fewer compute resources 🚀
https://www.graalvm.org
Other
20.38k stars 1.63k forks source link

Trim JFR event stack traces #7095

Open roberttoyonaga opened 1 year ago

roberttoyonaga commented 1 year ago

Feature request

Is your feature request related to a problem? Please describe. Currently, JFR stacktraces include all frames up to the point the stack walk is done. image This means that the last few frames in the stacktrace always display internal code and are probably not interesting to the user. This makes flamegraphs more cluttered than necessary and does not match the behavior of JFR in Java mode (shown below).
image

Describe the solution you'd like. It might be useful if the stacktraces were trimmed for each event where stacktraces are enabled such that they are similar to the ones obtained running in Java mode. The infrastructure to do this is already in place so the work should be very minimal. Setting the stacktrace skipcount from the point of event emission for each event should do the trick.

Describe who do you think will benefit the most. JFR users.

Describe alternatives you've considered. 1). Continue collecting the full stacktrace. This might be useful for those developing GraalVM. Collecting the full stacktrace also avoids having to update a hard-coded skipcount whenever the underlying JFR implementation changes (but this is probably a minor benefit).

2). Only trim the last ~3 frames that pertain to the actual stacktrace generation. Keep the other internal frames to assist with GraalVM development and debugging.

I think any of these options are reasonable, but that it's probably worth bringing up for discussion.

Express whether you'd like to help contributing this feature I can do this, if we decide this change is desirable.

jbachorik commented 9 months ago

If I can chime in - for a common profiler user those extra frames are quite distracting as they are the internal implementation of collecting the stacktrace. When this data is aggregated one can easily end up with the bottleneck pointing to the stacktrace collection code which is both incorrect and undesired.

I can imagine, for the Graal developers, there would be a config knob (eg. a system property) to set which would enable recording unredacted stack, but for the common use case it would be really helpful to have the frame where the stacktrace was collected to become the leaf of the stacktrace.