> 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 >> <mailto: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/ >> >> <https://mostlynerdless.de/blog/2025/06/11/java-25s-new-cpu-time-profiler-1/>
