[jdk19] RFR: 8280320: C2: Loop opts are missing during OSR compilation [v2]

[Vladimir Ivanov]

> After [JDK-8272330](https://bugs.openjdk.org/browse/JDK-8272330), OSR compilations may completely miss loop optimizations pass due to misleading profiling data. The cleanup changed how profile counts are scaled and it had surprising effect on OSR compilations. 
> 
> For a long-running loop it's common to have an MDO allocated during the first invocation while running in the loop. Also, OSR compilation may be scheduled while running the very first method invocation. In such case, `MethodData::invocation_counter() == 0` while `MethodData::backedge_counter() > 0`. Before JDK-8272330 went in, `ciMethod::scale_count()` took into account both `invocation_counter()` and `backedge_counter()`. Now `MethodData::invocation_counter()` is taken by `ciMethod::scale_count()` as is and it forces all counts to be unconditionally scaled to `1`. 
> 
> It misleads `IdealLoopTree::beautify_loops()` to believe there are no hot
> backedges in the loop being compiled and `IdealLoopTree::split_outer_loop()`
> doesn't kick in thus effectively blocking any further loop optimizations.
> 
> Proposed fix bumps `MethodData::invocation_counter()` from `0` to `1` and
> enables `ciMethod::scale_count()` to report sane numbers.
> 
> Testing: 
> - hs-tier1 - hs-tier4

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Improve comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk19/pull/38/files
  - new: https://git.openjdk.org/jdk19/pull/38/files/ce36c789..ffd6d78b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=38&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=38&range=00-01

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk19/pull/38.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/38/head:pull/38

PR: https://git.openjdk.org/jdk19/pull/38