> 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 Trying to disambiguate here.
"This API": we referring to our friendly simple exposed subset? Or are we referring to "you passed --raw and whatever is parsing that could drift." The former we have control over. The latter not so much. I'm +0 to taking on (and breaking) the latter; we either allow power users to pass arg strings directly and stay frozen if the API in the profiler changes, or we just rev the profile dep as needed and let power users eat the re-architecting costs. In my head: they're power users. They can update their profiler... profiles... locally; not so big a burden. On Sun, Jun 22, 2025, at 3:40 PM, David Capwell wrote: >> 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> 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/ >>>>
