Refactor py-spy & pyperf to separate ProfilerInterface.

[marcin-ol]

Refactor py-spy & pyperf to separate ProfilerInterface classes.

Description

Group profilers by common runtime (e.g.: Python, Java, etc.). Support automatic selection of best available profiler for each runtime.

Related Issue

500

Motivation and Context

We have PythonProfiler which is a class that hides the fact that we have 2 profiler types behind - py-spy or pyperf, and decides itself which one is used. There was no mechanism to support multiple profiler options and keep them separate. More profilers will arrive in future that will benefit from this.

Also: #448

How Has This Been Tested?

Additional tests developed for new mechanism, added tests to ensure correct behavior of Python profiling.

Checklist:

• [x] I have read the CONTRIBUTING document.
• [x] I have added tests for new logic.

[marcin-ol]

Remaining actions for this PR:

• [x] Register PySpyProfiler and EbpfProfiler separately for python, using developed mechanism.
• [x] Organize profilers options: supported modes, runtime arguments should be either well separated or declared with runtime (Python) itself.

[marcin-ol]

I reviewed most of it.

Issues/problems I spot:

1. Profilers still need to specify default_mode and possible_modes, which no longer makes sense as each profiler class now represents a single profiler and a single mode. IMO this is one of the problems we were trying to solve in this PR.

That would be okay but I see a few opportunities:

• SystemProfiler supports 3 possible on-modes: smart, dwarf, and fp. Either we refactor it with this PR (but that wouldn't align with the intention of this PR) or keep possible_modes for now, but add a new issue to solve it.
• python profiling won't be possible with "auto" mode, but I suppose it wasn't used frequently?

And issue with default_mode:

• DotnetProfiler is disabled by default, with use of default_mode parameter; I think we might still need it for newly introduced profilers. I propose to keep this argument but at the Runtime level, renamed to: enabled_by_default

2. As you mentioned, we lack the concept of "runtime arguments". This is visible for Python which has 2 profilers, and will be visible in others as well if we ever add more profielrs (e.g in Java, some of the arguments are truly async-profiler specific and some are not and will be relevant to any java profiler, e.g --java-collect-jvm-flags). "Runtime arguments" is where we could have placed the default_mode and possible_mode arguments.

My proposal:

1. let's add the concept of a runtime object, and profilers will be attached to their runtime object. When generating commandline arguments, they will be taken into account separately (i.e there will be a section "Java arguments" and then "Java async-profiler arguments").

I'm all for it. I wanted to make it clear (and convince myself too) that it's really needed, that's why I paused implementation at this stage.

2. possible_modes will be the default ones + the different registered runtime profilers for this runtime.

I agree we still need default mode - for the likes of DotnetProfiler and experimental ones.

3. At the same time we can rename JavaProfiler to JavaAsyncProfiler

And register with profiler_name=ap to support auto-generated possible_mode=ap?

4. This simplifies get_profiler_arguments

Sure.

[marcin-ol]

As discussed earlier, I have introduced runtime object in form of ProfilingRuntime. Runtime defines shared attributes of profilers: default_mode, mode_help, disablement_help and common_arguments.

• Few things were simplified - get_profiler_arguments, get_preferred_or_first_profiler were discarded, as now the common and profiler-specific arguments are separate.
• New concept was added - InternalArgument to handle arguments that are set in the code, not by arg parser, i.e.: perf_node_attach, perf_inject.

[Jongy]

I only briefly reviewed now.