RFR: 8354284: Add more compiler test folders to tier1 runs

[Marc Chevalier]

On Wed, 23 Apr 2025 08:44:04 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> Some folders in jtreg/compiler have been reported not to be run in any tier, while tier1 was probably intended, but the tier definition was mistakenly not updated. I've checked which folders are not referenced into `TEST.groups`.
> 
> The unmentioned ones:
> - `ccp`
> - `ciReplay`
> - `ciTypeFlow`
> - `compilercontrol`
> - `debug`
> - `oracle`
> - `predicates`
> - `print`
> - `relocations`
> - `sharedstubs`
> - `splitif`
> - `tiered`
> - `whitebox`
> 
> And those, that are not test folders:
> - `lib`
> - `patches`
> - `testlibraries`
> 
> I'm adding `ccp`, `ciTypeFlow`, `predicates`, `sharedstubs` and `splitif` to tier1.
> 
> The other folders seems to have been around for very long (since at least mid-2021). It's not clear how meaningful it'd be to add them/what the intent from them was. I've rather focused on the recently(-ish) added folders, that one forgot to put in a tier when adding it.
> 
> Feel free to tell if other folders should be included (and in which tier).
> 
> Thanks,
> Marc

Rather than simply removing the test from tier1, can we make it faster? (spoiler: yes). There are two big slow things:
- a `RepeatCompilation=300`:
  https://github.com/openjdk/jdk/blob/526951dba731f0e733e22a3bff7ac7a18ce9dece/test/hotspot/jtreg/compiler/ccp/TestAndConZeroCCP.java#L29-L30
  we can remove this flag entirely. It's useful for debugging, but tier1 is run often, we probably don't need this flag. It is good for debugging, but I think we usually don't include such flags in tests.
- a rather big loop:
  https://github.com/openjdk/jdk/blob/526951dba731f0e733e22a3bff7ac7a18ce9dece/test/hotspot/jtreg/compiler/ccp/TestAndConZeroCCP.java#L45-L47
  calling another rather big loop:
  https://github.com/openjdk/jdk/blob/526951dba731f0e733e22a3bff7ac7a18ce9dece/test/hotspot/jtreg/compiler/ccp/TestAndConZeroCCP.java#L51-L55
  that is overall 2^16 * 10^5 ~ 6.6e9 iterations. That's where most of the time is spent. But actually, the outer loop (with the `10000` bound) is not needed: I've reproduced the corresponding issue [JDK-8350563](https://bugs.openjdk.org/browse/JDK-8350563) replacing the loop by a mere `run()` and it still reproduces, and is working after the fix. The inner loop (with the `1 << 16` bound) cannot be shortened: the bound is necessary for having the correct range in some node types that triggers the bug. We also cannot make a much bigger step (`cp += 2` works, but not more), I'm not very sure why.

With these improvements, this test is doing much better! Running this test alone in testing takes only 1h18 of machine time when it used to take 2h30. The longer duration of a single result passed from 40s to 8s. I think with these changes, the test is still meaningful and is short enough for tier1. I you agree, I can push this tiny fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/24817#issuecomment-2841681522