Bug ID: JDK-8297343 TestStress*.java fail with "got different 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 20
20 b26Fixed

compiler/debug/TestStressCM.java and compiler/debug/TestStressIGVNAndCCP.java fail with "java.lang.RuntimeException: got different [CCP/code motion] traces for the same seed..."

The regression seems to be due to the introduction of non-determinism in the node dumps of otherwise identical compilations. 

E.g. one run dumps

282 ConI \=\=\= 0 [[ 229 ]] \#int\:6 java/lang/Class (java/io/Serializable,java/lang/constant/Constable,java/lang/reflect/AnnotatedElement,java/lang/invoke/TypeDescriptor,java/lang/reflect/GenericDeclaration,java/lang/reflect/Type,java/lang/invoke/TypeDescriptor$OfField)\:exact *

while the next (identical) run dumps

282 ConI \=\=\= 0 [[ 229 ]] \#int\:6 java/lang/Class (java/lang/reflect/AnnotatedElement,java/lang/invoke/TypeDescriptor,java/lang/reflect/GenericDeclaration,java/lang/reflect/Type,java/lang/invoke/TypeDescriptor$OfField,java/io/Serializable,java/lang/constant/Constable)\:exact *

So far, the failure has only been observed in macosx builds (both x64 and aarch64).

Changeset: eff4c039 Author: Roland Westrelin <roland@openjdk.org> Date: 2022-11-28 12:27:14 +0000 URL: https://git.openjdk.org/jdk/commit/eff4c039dab99aa946dbdde1be8901929ebbfc6f
28-11-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/11357 Date: 2022-11-24 15:27:41 +0000
24-11-2022
[~rcastanedalo] thanks for taking the time to do that.
24-11-2022
[~roland] I tested your patch on macOS and it fixes the issue (did not see any failure in 20 runs of each test, whereas before the patch each test fails about 75% of the times).
24-11-2022
Thanks, I will try it out.
24-11-2022
[~rcastanedalo] Is this easily reproducible (I don't have a macos system to try it on)? If so could you give: https://github.com/rwestrel/jdk/tree/JDK-8297343 a try?
23-11-2022
[~roland] Sure, that would be great since you are obviously more knowledgeable about this code. Thanks Roland!
22-11-2022
[~rcastanedalo] it does. Dumping in a stable order is reasonable for sure. Would you like me to take care of it?
22-11-2022
[~thartmann] I will have a look. The problem seems to be that JDK-6312651 dumps interface sets in an order that is determined by the raw pointers of the set elements. This is unstable across different runs and leads to different node dumps for otherwise identical compilations. Stable node dumps are useful for debugging (e.g. when diffing compiler traces from two different runs), so the solution is probably dumping interface sets in some order (e.g. lexicographic order of each interface dump) that does not depend on raw pointer values. [~roland] does that make sense to you?
22-11-2022
ILW = test failure, likely due to test / dumping bug; frequent on macOS; ignore test failures = MHM = P3
21-11-2022
The failure is likely introduced by JDK-6312651.
21-11-2022