RFR: 8341039: compiler/cha/TypeProfileFinalMethod.java fails with assertEquals expected: 0 but was: 2

[Daniel Lundén]

On Mon, 10 Nov 2025 07:25:57 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> The test `compiler/cha/TypeProfileFinalMethod.java` exercises a specific compilation pattern and easily breaks by setting various VM flags (e.g., `-Xcomp`).
>> 
>> ### Changeset
>> 
>> - Make the test flagless.
>> - Ensure the test only compiles the intended methods.
>> - Fix problems with compiler directives used in the test (incorrect signatures and some directives getting unintentionally shadowed by other directives).
>> - Force C2 inlining of a method which the test author likely intended to always be inlined (based on source code comments in the test).
>> - Switch argument order in `assertEquals` to make error message correct.
>> 
>> Note for reviewers: A more fundamental rewrite of the test is beyond the scope of this changeset. The objective here is simply to ensure the test runs only in contexts intended by the test author.
>> 
>> ### Testing
>> 
>> - [GitHub Actions](https://github.com/dlunde/jdk/actions/runs/18972906513)
>> - `tier1` and HotSpot parts of `tier2` and `tier3` (and additional Oracle-internal testing) on Windows x64, Linux x64, Linux aarch64, macOS x64, and macOS aarch64.
>> - Stress testing of the specific test on Windows x64, Linux x64, Linux aarch64, macOS x64, and macOS aarch64.
>
> test/hotspot/jtreg/compiler/cha/TypeProfileFinalMethod.java line 28:
> 
>> 26:  * @test
>> 27:  * @summary test c1 to record type profile with CHA optimization
>> 28:  * @requires vm.flavor == "server" & vm.flagless
> 
> I guess this change is part of the "Make the test flagless" part (and `TieredStopAtLevel` filters seem anyway a bit odd) but did you figure out why this was added first? Was it possibly just a mistake (since we create a new process anyway)?

Thanks for the review @dafedafe!

> I guess this change is part of the "Make the test flagless" part (and TieredStopAtLevel filters seem anyway a bit odd) but did you figure out why this was added first?

I would guess the conditions for `TieredStopAtLevel` were added to ensure this particular flag could not break the test. However, there are many other flags that can also break the test. Hence, we need flagless (which subsumes the `TieredStopAtLevel` conditions).

> Was it possibly just a mistake (since we create a new process anyway)?

The `createTestJavaProcessBuilder` method adds the default jvm options from jtreg, test.vm.opts and test.java.opts (see the source code comment for `createTestJavaProcessBuilder`). So no, not a mistake, but also not a complete safeguard.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28200#discussion_r2510348285