<div dir="ltr">Hi Aleksey,<div><br></div><div>Thank you for the answer!</div><div>I'd rather discuss a few questions here and then file an issue in JBS and open a PR.</div><div><br></div><div>So, to the questions (sorry for being so verbose).</div><div><br></div><div>In terms of interaction, xctrace works almost the same way as perf. The main difference is what kind of artifact the tool produces at the end. </div><div>xctrace (and Instruments) creates a directory with a bunch of files (symbols, some metadata, and tables with raw and processed events), not a single file.<br>That is quite unfortunate as existing temp files (and a logic copying it on demand [1]) from the AbstractPerfAsmProfiler could not be reused. <br>But moving the copying logic into a separate open method and then overriding that method for xctrace-based profiler should do the trick without complicating things too much.</div><div><br>To use these profiling/tracing results on the JMH side, a proper table needs to be extracted and the only supported export format is XML.<br>There are several profiling instruments built-in into Instruments, namely:<br>- "Time Profiler", which is a good old timer-based sampling profiler;<br>- "CPU Profiler", which is a PMI based profiler;<br>- "CPU Counters" instrument, which could be used as a PMI based profiler with an arbitrary event's counter as an interrupts source (L1 load missed, for example).<br><br>Each of these instruments produces results in very similar yet slightly different formats. <br>It doesn't require any external dependencies, the good old org.xml.sax is enough, but it leads to a decent amount of code responsible for XML parsing (like here [2]).</div><div>I hope that won't be a problem (as a bonus, XML could bring that enterprise spirit to JMH ;)<br><br>In terms of the profiler usage, an instrument (or a template) name could be a profiler's parameter with a "Time Profiler" as a safe and robust default.<br><br>For the xctrace-based ASM-profiler, that's all possible technical issues I foresee (modulo the testing and a chance that Apple will make an incompatible change in a new XCode release).<br></div><div><br></div><div><br></div><div>But there's one more thing: it's also possible to implement a 'perf stat'-ish profiler (like LinuxPerfNormProfiler).</div><div>Here things become really ugly, as there is no safe default like for the ASM-profiler (you can't ask for cycles and instructions by default).<br>So a user has to configure a template with all PMU counters they need and then pass the template name as a profiler's parameter. <br>And only then can one get their IPC/CPI, cache miss ratio or any other metrics (but there are also some caveats, and xctrace does not support PMU events multiplexing, so all you have are ~8 counters, at most).<br><br>For the PMU counters, an XML parser from the ASM-profile could be reused.</div><div><br>But it's possible to include results from all other available instruments (virtual memory stats, scheduling info, syscall statistics, etc.),</div><div>although, I, personally, didn't have an urge to use any of it so far.<br>As you may already guessed, all these instruments have their own XML-schemas for results and it all needs to be parsed and aggregated.<br>I see a few options here:<br>- support only PMU counters as a statistics source;<br>- supporting all possible table formats (I'm not really serious proposing it);<br>- follow the JFR-profiler design [3] and allow users to provide their own parsers and aggregators that will handle all these extra tables.<br><br>Yet another option, of course, is to abstain from adding that perf-stat-ish profiler, but I sometimes find PMU counters stats pretty insightful.<br></div><div>Anyway, I guess it could be discussed/added/thrown to a garbage bin separately from PerfAsm-profiler.</div><div><br></div><div>Best regards,</div><div>Filipp.</div><div><br></div><div>[1] <a href="https://github.com/openjdk/jmh/blob/641f0480632f47e0dbdbf454105bbda550dd5eb7/jmh-core/src/main/java/org/openjdk/jmh/profile/AbstractPerfAsmProfiler.java#L681">https://github.com/openjdk/jmh/blob/641f0480632f47e0dbdbf454105bbda550dd5eb7/jmh-core/src/main/java/org/openjdk/jmh/profile/AbstractPerfAsmProfiler.java#L681</a></div><div>[2] <a href="https://github.com/fzhinkin/xctraceprof/blob/main/profiler/src/main/java/org/openjdk/jmh/profile/XCTraceTableHandler.java">https://github.com/fzhinkin/xctraceprof/blob/main/profiler/src/main/java/org/openjdk/jmh/profile/XCTraceTableHandler.java</a></div><div>[3] <a href="https://github.com/openjdk/jmh/blob/641f0480632f47e0dbdbf454105bbda550dd5eb7/jmh-core/src/main/java/org/openjdk/jmh/profile/JavaFlightRecorderProfiler.java#L270">https://github.com/openjdk/jmh/blob/641f0480632f47e0dbdbf454105bbda550dd5eb7/jmh-core/src/main/java/org/openjdk/jmh/profile/JavaFlightRecorderProfiler.java#L270</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 11 Mar 2024 at 20:21, Aleksey Shipilev <<a href="mailto:shipilev@amazon.de">shipilev@amazon.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Filipp,<br>
<br>
On 11.03.24 19:06, Filipp Zhinkin wrote:<br>
> How do you feel about adding a new JMH ASM-profiler wrapping the xctrace tool?<br>
<br>
I am all for it! Having a perfasm-like profiler on Mac would be a good productivity improvement. Not <br>
even sure that dtraceasm is salvageable on modern MacOS-es, especially on corporate managed ones <br>
that have opinions on tools running under superuser privileges. So I don't see this as duplicate work.<br>
<br>
Feel free to propose a PR or discuss the questions here. If you cannot submit a related bug in JBS, <br>
I would submit it after the PR is there.<br>
<br>
Thanks,<br>
-Aleksey<br>
<br>
<br>
<br>
<br>
<br>
Amazon Development Center Germany GmbH<br>
Krausenstr. 38<br>
10117 Berlin<br>
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss<br>
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B<br>
Sitz: Berlin<br>
Ust-ID: DE 289 237 879<br>
<br>
<br>
</blockquote></div>