Enforce/Disable IProfiler during startup phase with -XX:[+/-]IProfileDuringStartupPhase

[rmnattas]

Issue or pull request number:
eclipse-openj9/openj9#18381

Overview:
Making a new option, -XX:[+/-]IProfileDuringStartupPhase, to enforce/disable IProfiler during the startup phase, it will replaces the TR_DisableNoIProfilerDuringStartupPhase environment variable and overrides Xjit:noIProfilerDuringStartupPhase.

If not used, the default algorithm is used to determine the behaviour.

This option will be used in populate_scc scripts to ensure more IProfiler information are being collected and stored in the SCC.

Release target:
Eclipse OpenJ9 0.42

Applies to the following JDK versions:
ALL

Applies to the following platforms:
ALL

For new command line options:

• Option name and syntax: -XX:[+/-]IProfileDuringStartupPhase
• Purpose: Enforce/Disable IProfiler during startup phase.
• Restrictions: None

[Sreekala-Gopakumar]

@rmnattas - What is the default state of this option?
What is iProfiler used for?
What was the problem that was happening because of which this new option was added?

Thanks!

[rmnattas]

There's no default value, the default behaviour depends on different factors of the SCC properties to decide to either do "I-Profiler during startup phase" or not. This option either enforce or prevent doing "I-Profiler during startup phase" regardless of the SCC properties.

I-Profiler is used to collect profiling information on a method to help optimize it when it gets JIT compiled. Reason of it being disabled at startup sometimes is that if the SCC already has I-Profiler information stored, then there's no need to collect new info and affect performance.

Reason of adding this is to be able to enforce "I-Profiler during startup phase" when doing cold-runs that their purpose is to populate the SCC before actual production runs.

[Sreekala-Gopakumar]

There's no default value, the default behaviour depends on different factors of the SCC properties to decide to either do "I-Profiler during startup phase" or not. This option either enforce or prevent doing "I-Profiler during startup phase" regardless of the SCC properties.

I-Profiler is used to collect profiling information on a method to help optimize it when it gets JIT compiled. Reason of it being disabled at startup sometimes is that if the SCC already has I-Profiler information stored, then there's no need to collect new info and affect performance.

Reason of adding this is to be able to enforce "I-Profiler during startup phase" when doing cold-runs that their purpose is to populate the SCC before actual production runs.

Usually, such options always have a default state. For example, https://eclipse.dev/openj9/docs/xxexitonoutofmemoryerror/, https://eclipse.dev/openj9/docs/xxenablecpumonitor/, https://eclipse.dev/openj9/docs/xxdisableexplicitgc/. So, at a point of time where you have to decide whether to enforce or prevent doing ""I-Profiler during startup phase" regardless of the SCC properties, is -XX:-IProfileDuringStartupPhase, the default selection?

[rmnattas]

So, at a point of time where you have to decide whether to enforce or prevent doing ""I-Profiler during startup phase" regardless of the SCC properties, is -XX:-IProfileDuringStartupPhase, the default selection?

There's no default selection here, because the option does the extremes of "always enforcing" or "always preventing", while the default (not using either -XX:[+/-]IProfileDuringStartupPhase) is an indeterministic behaviour of may or may not "I-Profiler during startup phase" depend on the used SCC properties, which is the default before this option was created and still the default now.

[Sreekala-Gopakumar]

There's no default value, the default behaviour depends on different factors of the SCC properties to decide to either do "I-Profiler during startup phase" or not. This option either enforce or prevent doing "I-Profiler during startup phase" regardless of the SCC properties.

I-Profiler is used to collect profiling information on a method to help optimize it when it gets JIT compiled. Reason of it being disabled at startup sometimes is that if the SCC already has I-Profiler information stored, then there's no need to collect new info and affect performance.

Reason of adding this is to be able to enforce "I-Profiler during startup phase" when doing cold-runs that their purpose is to populate the SCC before actual production runs.

What do you mean by cold runs and warm runs? Are these referring to the optimisation levels? Could you please give a little more explanation for this so that I can be clear about what I am writing.

Also, "startup phase" of what? of the client VM or the application?

Thanks!

[rmnattas]

What do you mean by cold runs and warm runs? Are these referring to the optimisation levels? Could you please give a little more explanation for this so that I can be clear about what I am writing.

Cold run is at least what we call doing a mimicking short run of the application to build up the cache/SCC when setting-up the environment. Hence the actual production run (warm run) after is better with having such cache.
I'm not sure if docs need to get into much of this details, over just the effect of the option, but idk.

Also, "startup phase" of what? of the client VM or the application?

The startup phase of the JVM in general, which can behave slightly differently than the rest of the JVM lifetime to balance between a quick startup for the application running on the JVM and overall performance.