Reduce counts when class of method is not in SCC

[mpirvu]

By default, OpenJ9 uses an "implicit" shared class cache (SCC) that is used to cache "bootstrap" classes and methods. Currently, methods whose class is not present in the SCC receive a high initial invocation count (3000/3000 for loopless/loopy method) in order to improve steady state throughput. However, this could affect start-up time of applications because methods are interpreted for too long before being JIT compiled.
The presence of -Xshareclasses on the command line is a sign that the user cares about start-up time and OpenJ9 automatically lowers the invocations counts to 1000/250. However, with the implicit SCC (no -Xshareclasses command line option), application classes are not cached and methods belonging to those classes will receive a large initial invocation count (3000/3000). Since application classes are likely important, we would like to use lower counts even when the implict SCC is used.

This commit lowers the initial invocation counts for methods whose class is not in SCC under the following conditions:

• SCC is used. Rationale: -Xshareclasses:none may be a sign that user does not care about start-up that much.
• -Xtune:throughput is not used. Rationale: this option is a clear signal that the user cares more about throughput than startup.
• The user has not provided a specific count on the command line.
• The JVM is in start-up mode. Rationale: this feature only seeks to improve start-up time.
• The JVM runs on 4 or more vCPUs. Rationale: lower counts will generate more compilations which will compete with application

Depends on eclipse/omr/#7156

[mpirvu]

jenkins test sanity zlinuxjit jdk17 depends eclipse/omr#7156

[vijaysun-omr]

What is your thinking on applying lower counts during rampup phase ? i.e. in addition to startup phase.

[mpirvu]

I don't think lowering counts during rampup will improve DaCapo further. DaCapo benchmarks don't have a startup phase per-se, so the JIT estimates one, which is quite long.
Moreover, counts are set when classes are loaded. The rampup phase is characterized by many first time compilations and (especially) recompilations. When this happens, the classes have already been loaded and counts set.
A tweak could be to look at JIT startup phase (which can happen many times if the application has phase changes and loads many classes all of a sudden) as opposed to the VM start-up phase which can happen only once.

[vijaysun-omr]

Okay I wasn't thinking so much about Dacapo alone, though obviously it is a relevant fact if lower counts during rampup might help there too. I understand the point about rampup essentially being "too late". I'll defer to your best judgement on the JIT startup vs VM startup question since I don't have a good feel about that. Either way, please let me know if/when there are to be no further changes, so that I know when to consider final review and merge.

[mpirvu]

I don't plan to do any changes at the moment so this PR can be delivered as is.
Later on I may experiment with lowering the counts during the JIT start-up phase as opposed to the VM start-up phase as it is now. This (future) change carries more risk (negatively affecting steady state throughput).