MacOs ASM-profiler based on xctrace/Instruments

[Filipp Zhinkin]

Hi Aleksey,

Thank you for the answer!
I'd rather discuss a few questions here and then file an issue in JBS and
open a PR.

So, to the questions (sorry for being so verbose).

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.
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.
That is quite unfortunate as existing temp files (and a logic copying it on
demand [1]) from the AbstractPerfAsmProfiler could not be reused.
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.

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.
There are several profiling instruments built-in into Instruments, namely:
- "Time Profiler", which is a good old timer-based sampling profiler;
- "CPU Profiler", which is a PMI based profiler;
- "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).

Each of these instruments produces results in very similar yet slightly
different formats.
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]).
I hope that won't be a problem (as a bonus, XML could bring that enterprise
spirit to JMH ;)

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.

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).


But there's one more thing: it's also possible to implement a 'perf
stat'-ish profiler (like LinuxPerfNormProfiler).
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).
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.
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).

For the PMU counters, an XML parser from the ASM-profile could be reused.

But it's possible to include results from all other available instruments
(virtual memory stats, scheduling info, syscall statistics, etc.),
although, I, personally, didn't have an urge to use any of it so far.
As you may already guessed, all these instruments have their own
XML-schemas for results and it all needs to be parsed and aggregated.
I see a few options here:
- support only PMU counters as a statistics source;
- supporting all possible table formats (I'm not really serious proposing
it);
- follow the JFR-profiler design [3] and allow users to provide their own
parsers and aggregators that will handle all these extra tables.

Yet another option, of course, is to abstain from adding that perf-stat-ish
profiler, but I sometimes find PMU counters stats pretty insightful.
Anyway, I guess it could be discussed/added/thrown to a garbage bin
separately from PerfAsm-profiler.

Best regards,
Filipp.

[1]
https://github.com/openjdk/jmh/blob/641f0480632f47e0dbdbf454105bbda550dd5eb7/jmh-core/src/main/java/org/openjdk/jmh/profile/AbstractPerfAsmProfiler.java#L681
[2]
https://github.com/fzhinkin/xctraceprof/blob/main/profiler/src/main/java/org/openjdk/jmh/profile/XCTraceTableHandler.java
[3]
https://github.com/openjdk/jmh/blob/641f0480632f47e0dbdbf454105bbda550dd5eb7/jmh-core/src/main/java/org/openjdk/jmh/profile/JavaFlightRecorderProfiler.java#L270

On Mon, 11 Mar 2024 at 20:21, Aleksey Shipilev <shipilev at amazon.de> wrote:

> Hi Filipp,
>
> On 11.03.24 19:06, Filipp Zhinkin wrote:
> > How do you feel about adding a new JMH ASM-profiler wrapping the xctrace
> tool?
>
> I am all for it! Having a perfasm-like profiler on Mac would be a good
> productivity improvement. Not
> even sure that dtraceasm is salvageable on modern MacOS-es, especially on
> corporate managed ones
> that have opinions on tools running under superuser privileges. So I don't
> see this as duplicate work.
>
> Feel free to propose a PR or discuss the questions here. If you cannot
> submit a related bug in JBS,
> I would submit it after the PR is there.
>
> Thanks,
> -Aleksey
>
>
>
>
>
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jmh-dev/attachments/20240312/767794ec/attachment.htm>