Bug ID: JDK-8348658 [AArch64] The node limit in compiler/codegen/TestMatcherClone.java is too strict

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 24	JDK 25
24Fixed	25 b09Fixed

# Failure analysis

On some aarch64 machines, the node limit in compiler/codegen/TestMatcherClone.java is too strict.

# Original description

The test added by JDK-8331295 reliably fails on my Graviton 3 instance. This is not a new failure, I can see it fails at 7d4c3fd0915cfa8b279f42494625ec6afda338af (JDK-8331295) as well, so it was there from the beginning.

% CONF=linux-aarch64-server-fastdebug make test TEST=compiler/codegen/TestMatcherClone.java

1) Method "public void compiler.codegen.TestMatcherClone.test()" - [Failed IR rules: 1]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={MATCHING}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#C#ADD_P_OF#_", "reg_imm", "<200"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
     > Phase "After matching":
       - counts: Graph contains wrong number of nodes:
         * Constraint 1: "(\d+(\s){2}(addP_reg_imm.*)+(\s){2}===.*.*)"
           - Failed comparison: [found] 350 < 200 [given]
             - Matched nodes (350):
               * 3506  addP_reg_imm  === _ 0 3507  [[ 3502 3528 10313 10312 10311 ]] #24/0x0000000000000018rawptr:BotPTR
               * 3519  addP_reg_imm  === _ 3507 3507  [[ 3518 ]] #16/0x0000000000000010rawptr:BotPTR

A pull request was submitted for review. Branch: jdk24 URL: https://git.openjdk.org/jdk/pull/23390 Date: 2025-01-31 14:25:30 +0000
31-01-2025
Changeset: ee87d187 Branch: master Author: Daniel Lundén <dlunden@openjdk.org> Date: 2025-01-31 14:09:15 +0000 URL: https://git.openjdk.org/jdk/commit/ee87d187d1cab09317b4f0068bfafc68efbbfe56
31-01-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/23349 Date: 2025-01-29 15:33:43 +0000
29-01-2025
Thanks for confirming [~shade]. Yes, let's increase it to 400. I'll create a PR.
28-01-2025
> Any chance to get access to a Graviton 3 instance? Yeah, this is a regular m7g instance in EC2, these are publicly available. > [~shade] Can you to run the test on the commit prior to JDK-8331295 and see what the "found" count is in the error message? mainline says: - Failed comparison: [found] 350 < 200 [given] 7d4c3fd0915cfa8b279f42494625ec6afda338af (JDK-8331295) says: - Failed comparison: [found] 350 < 200 [given] 7d4c3fd0915cfa8b279f42494625ec6afda338af with the product parts of JDK-8331295 reverted says: - Failed comparison: [found] 696 < 200 [given] So I guess we should put "400"?
28-01-2025
I am not able to reproduce the failure on the aarch64 machine I have available. [~shade] Any chance to get access to a Graviton 3 instance? It could simply be that the test limit of 200 is too strict. For comparison, before JDK-8331295, the test failure on my aarch64 machine indicates - Failed comparison: [found] 522 < 200 [given] [~shade] Can you to run the test on the commit prior to JDK-8331295 and see what the "found" count is in the error message? If the count is significantly higher then, compared to the 350 count now, the fix in JDK-8331295 works as expected and I suggest we simply increase the limit slightly above 350. If the count is the same, we need to have a closer look.
28-01-2025
I'm marking / triaging this as test bug for now, please adjust if it turns out to be a product issue. ILW = Test fails due to unexpected number of addp in generated code, single test on Graviton 3, no workaround = MLH = P4
28-01-2025