Bug ID: JDK-8311279 TestStressIGVNAndCCP.java failed with different IGVN traces for the same seed

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 21	JDK 22
21.0.3-oracleFixed	22 b06Fixed

Test message: "got different IGVN traces for the same seed" (for the seed value of "0", AFAIU).

Please find output diff (a pretty messy one) attached. 

The test arguments were:

'-ea -esa -Dcom.oracle.usagetracker.config.file=<some_config_file>'

Usage tracker config contents, just in case:
com.oracle.usagetracker.logToFile=<some_path>/usage-tracker.log

Fix request [21u] I backport this for parity with 21.0.3-oracle. No risk, only a test change. Clean backport. Test passes. SAP nightly testing passed.
04-01-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk21u-dev/pull/113 Date: 2024-01-03 08:15:33 +0000
03-01-2024
Changeset: edb2be10 Author: Christian Hagedorn <chagedorn@openjdk.org> Date: 2023-07-06 06:32:05 +0000 URL: https://git.openjdk.org/jdk/commit/edb2be10fb897834ed78ab4493d3a4f73dc2e140
06-07-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/14771 Date: 2023-07-05 09:10:48 +0000
05-07-2023
Looking at the output, it seems that one run got compile id 1, while the other one got compile id 2. This makes a difference for the debug_idx which is printed for a dead node as "compile id * 10000000000 + node index": compile id 1: CompileCommand\: compileonly compiler/debug/TestStressIGVNAndCCP.sum bool compileonly \= true < < 80 Phi \=\=\= _ _ _ [[ ]] [10000000080] ... compile id 2: CompileCommand\: compileonly compiler/debug/TestStressIGVNAndCCP.sum bool compileonly \= true < < 80 Phi \=\=\= _ _ _ [[ ]] [20000000080] ... I was not able to reproduce this but my suspicion is that in one VM, we've compiled a native method wrapper or a method handle intrinsic but not in the other one. This would explain the different compile id because we are always only compiling a single method with the given JVM flags. A native compilation can be triggered, for example, by passing -esa: 60 1 n java.lang.invoke.MethodHandle::invokeBasic()I (native) 60 2 n java.lang.invoke.MethodHandle::linkToSpecial(LL)I (native) (static) 69 3 b compiler.debug.TestStressIGVNAndCCP::sum (27 bytes) To fix this, we could use the -XX:+CICountNative flag which uses a separate counter for native compilations: 50 1 n java.lang.invoke.MethodHandle::invokeBasic()I (native) 51 2 n java.lang.invoke.MethodHandle::linkToSpecial(LL)I (native) (static) 59 1 b compiler.debug.TestStressIGVNAndCCP::sum (27 bytes) This is the same approach as done in JDK-8269342 to reliably crash with -XX:CICrashAt=1 in the first compilation.
04-07-2023
ILW = Single harmless test failure, rare, no workaround = LLH = P5
04-07-2023