Java 20, and possibly earlier versions, generate lambda method names with unique numerical suffixes: the lambda defined at a particular point in code may show up with a multitude of different frame names, preventing logically identical stacks from being coalesced. While it is in some sense "correct" to distinguish lambdas might have captured different local variables, the distinction is not helpful for profiling.

We therefore been stripping the suffixes when generating flame graphs (and speedscope input) from async-profiler-generated jfr and collapsed dumps. While our approach uses string manipulation on async-profiler output, there may be an advantage to doing it in async-profiler itself. For example, our approach does not prevent proliferation of essentially identical entries in call stack storage.