> it sounds like you’re saying users who actually use the profiler today are > SOL and need to roll their own solution.
No, I am saying it’s good to have sidecar expose this and expose common patterns that people actually use. If sidecar wishes to expose exec and take the fact that this API could break on it, I am +0 to that. I mostly am trying to highlight the risk > On Jun 20, 2025, at 2:54 PM, Jon Haddad <j...@rustyrazorblade.com> wrote: > > 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 > <mailto: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 >>> <mailto: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/> >>
