Well, the discussion is about sidecar doing it. it sounds like you’re saying users who actually use the profiler today are SOL and need to roll their own solution.
On Fri, Jun 20, 2025 at 10:24 AM David Capwell <dcapw...@apple.com> wrote: > However, for folks like me that know the command line options and > regularly do things that you might not have planned out, I'd appreciate an > escape hatch where I can pass my raw commands > > > For more “advanced” users, normal profile.sh would still be able to > profile, just requires more steps. > > I think supporting both an abstraction-layer bound "simple mode" and a > "--raw for experts" is the way to go. > > > How do we say “this API has 0 compatibility for C* and can break w/e”? > > On Jun 20, 2025, at 5:22 AM, Josh McKenzie <jmcken...@apache.org> wrote: > > I think supporting both an abstraction-layer bound "simple mode" and a > "--raw for experts" is the way to go. > > On Thu, Jun 19, 2025, at 1:23 PM, Jon Haddad wrote: > > I understand the motivation to decouple the command line configuration > from what we expose to end users, and to an extent, agree with the > reasoning. However, for folks like me that know the command line options > and regularly do things that you might not have planned out, I'd appreciate > an escape hatch where I can pass my raw commands. Whatever you end up > implementing, there's almost certainly commands that experienced > async-profiler folks will want to use that weren't planned for. > > I am also not particularly interested in learning another syntax only to > have it transformed into the thing I want to use. I expect that would be a > fairly simple flag (nodetool profile --raw xyz) that would skip the parse > logic, so hopefully it's not too much trouble to add. Reverse engineering > the async profiler syntax into the thing we decide to use is, at least for > me, will be a source of frustration. > > Thanks, > Jon > > > > On Wed, Jun 18, 2025 at 4:01 PM Abe Ratnofsky <a...@aber.io> wrote: > > Another vote in favor of including async-profiler as a library in C*. The > new heatmap format in async-profiler 4.0[1] is excellent and makes > long-running profiles miles more useful than a plain flamegraph, but it > requires a post-processing step after a JFR is collected, which would > require a dependency on jfr-converter.jar[2]. Exposing the JFR files > directly would be reasonable but slightly less useful, and the > post-processed heatmap HTML files are much smaller and self-contained. A > recent example on my machine shows HTML at 1/20th the size of the raw JFR > dump, which is meaningful especially for uploading to Jira. > > Note that JDK25 will have experimental support for better CPU > profiling[3], but async-profiler is still more mature and featureful, > especially for other profiling types (wall, alloc). > > [1]: > https://github.com/async-profiler/async-profiler/blob/master/docs/Heatmap.md > [2]: > https://github.com/async-profiler/async-profiler?tab=readme-ov-file#stable-release-40 > [3]: > https://mostlynerdless.de/blog/2025/06/11/java-25s-new-cpu-time-profiler-1/ > > > >
