RFR: 7903722: JMH: Add xctrace-based perfnorm profiler for macOS
Filipp Zhinkin
fzhinkin at openjdk.org
Mon Sep 23 16:10:49 UTC 2024
On Fri, 20 Sep 2024 18:20:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> @shipilev hey! Does it make any sense to keep this PR open (and continuing working on it)?
>> I guess, the immense amount of changes blocks this PR from being reviewed in a reasonable time frame. I'd love to throw away as much code as possible (see https://github.com/openjdk/jmh/pull/131#issuecomment-2131129163; also Summary's "Here are some alternatives to existing implementation (of default parameters mode, mostly)" portion), but to keep the profiler as user-friendly as, for instance, `perfnorm`, some portion of logic gluing all parts together have to be preserved.
>>
>> Please let me know what would work better (if anything).
>
> Hi @fzhinkin! Sorry, the delays are my fault, I keep getting distracted to other things, and this is a huge PR.
>
> I think we should indeed consider trimming down things that we do here. This is an impressive piece of work, but I cannot help but think how clunky this MacOS profiling interface really is. Building a package to configure a profiler, wow, what a hassle.
>
> If we commit to do an extended thing here, it would be harder to retract. If we start small, maybe we do not really need to extend it any in future. So I think we should be doing a favor to ourselves here, and only implement a very basic support: no building packages, no selectable events, a preconfigured template (which we might later conditionalize on xcode version?) with most useful events, an ability to substitute your own template (for power users). Yes, it would not be as great as `perfnorm`, but that's the tradeoff we make not to deal with the profiling interface clunkiness.
>
> Does that work?
>
> To hopefully answer the specific questions:
>
>> Currently, only PMU sampling was supported, however, profiler may also sample some software events like context switches, virtual memory operations and syscall statistics. It's unclear if all that should ever be supported.
>
> No need to make it even more complicated. Scope it out of this PR.
>
>> Some parts of the profiling process, [...] Tests functions are package-private in jmh-core, so to test them on it module I had to call everything through reflection, which definitely doesn't look good. I'm not sure how to both keep the API private and test in another module, so I'm looking forward to any advice on that.
>
> Reflection is fine for now. If this becomes a real burden, we can rethink how tests are factored.
>
>> CPU Counters doesn't work inside VMs [...], so all positive profiler's tests are currently skipped inside GH agents. I'm not sure what could be done here to improve testability.
>
> Skipping tests in GHA if GHA runners cannot support them is fine.
@shipilev
> I tried on my Mac, and I think profiler requires super-user privileges? I only succeeded when running `sudo java ....`
It should not require super-user privileges. Otherwise, `xctraceasm` will require them too.
Could you please elaborate on what happened w/o SU-privileges?
-------------
PR Comment: https://git.openjdk.org/jmh/pull/131#issuecomment-2368737923
More information about the jmh-dev
mailing list