JMH and ocperf

[Sergey Melnikov]

Hi,

Correct me, if I didn't understand you right.

In fact, pmu-tools/ocperf does it. Let's treat ocperf as one more
system-wide event-based profiler. But ocperf is just a wrapper over
perf which passes flags to perf. Therefore, ocperf's output format and
perf's one are equal. So, there is not need to write one more profiler
parser.

So, I believe there are two options:

1. Use current Perf infrastructure (classes) in JMH and let user to
overwrite executable name via environment variable. Thus, we will use
the same parser as perfasm and changes are minimal. Moreover, user is
fully responsible for issues of incompatibility between actual
executable output and perf's reference output.  I suggested this
approach in my first letter.
2. Add one more profiler visible from '-lprof' flag output. In this
approach it'd required to introduce new classes responsible for new
profiles and register them as 'Profiler' in JMH internals. These
classes should share code with perfasm's parser (we don't want to have
2 parsers for the same format, isn't it?). I believe it'll make JMH
code slightly more difficult to understand. Also, it makes us to
support this parser and be responsible for all issues of this parser.

Yes, I agree the second way is a bit 'more right', but I'm not sure it
worth to be implemented because there is no so many people who is
interested in such a deep analysis. Also, environment variable
overriding is user's area of responsibility and don't make us to
support additional code.

But anyway, it's just my point of view. If you disagree, I can
implement the second approach.

--Sergey

On Fri, Nov 18, 2016 at 12:35 PM, Aleksey Shipilev <shade at redhat.com> wrote:
> Hi,
>
> On 11/17/2016 09:57 PM, Sergey Melnikov wrote:
>> So, I'd like to propose to modify JMH a bit: to let user to overwrite
>> 'perf' executable name via environment variable. It let to use ocperf
>> with JMH and to specify symbolic names via JMH parameters.
>>
>> Therefore, JMH run will look like:
>>
>> $ PERF=ocperf.py java -jar target/benchmarks.jar -prof
>> perfasm:event=br_inst_retired.far_branch
>>
>> Alexey, what do you think, if I implement this functionality, will it
>> be possible to merge fix to trunk?
>
> I am not resistant to the idea, but I am missing something here.
>
> Why can't pmu-tools project provide the system/user-wide alternative for
> perf, so that JMH and others just use that instead of hacking the
> specifics in? This would seems like a proper way to do interop between
> the tools.
>
> Thanks,
> -Aleksey
>



-- 

--Sergey