JDK-8254602 : compiler/debug/TestStressCM.java failed with "RuntimeException: got the same optimization stats for different seeds: expected 45"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 16
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-10-12
  • Updated: 2020-10-19
  • Resolved: 2020-10-14
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 16
16 b20Fixed
Related Reports
Relates :  
Relates :  
Sub Tasks
JDK-8254610 :  
Description
The following test failed in the JDK16 CI:

compiler/debug/TestStressCM.java

Here's a snippet from the log file:

----------System.err:(47/2272)----------
java.lang.RuntimeException: got the same optimization stats for different seeds: expected 45
--- Compiler Statistics ---
Methods seen: 1  Methods parsed: 1  Nodes created: 1979
Blocks parsed: 5  Blocks seen: 5
0 made implicit ( 0%)
CCP: 1  constants found: 0
Total frameslots = 0, Max frameslots = 0
Inserted 0 spill loads, 0 spill stores, 0 mem-mem moves and 0 copies.
Total load cost=      0, store cost =      0, mem-mem cost =  0.00, copy cost =     0.
Adjusted spill cost =       0.
Conservatively coalesced 37 copies, 0 pairs, 0 post alloc.
Average allocation trips 1.000000
High Pressure Blocks = 29, Low Pressure Blocks = 103
Nops added 0 bytes to total of 1936 bytes, for 0.00%
Peephole: peephole rules applied: 0
PhaseIdealLoop=7, sum _unique=1744
 to not equal 45
--- Compiler Statistics ---
Methods seen: 1  Methods parsed: 1  Nodes created: 1979
Blocks parsed: 5  Blocks seen: 5
0 made implicit ( 0%)
CCP: 1  constants found: 0
Total frameslots = 0, Max frameslots = 0
Inserted 0 spill loads, 0 spill stores, 0 mem-mem moves and 0 copies.
Total load cost=      0, store cost =      0, mem-mem cost =  0.00, copy cost =     0.
Adjusted spill cost =       0.
Conservatively coalesced 37 copies, 0 pairs, 0 post alloc.
Average allocation trips 1.000000
High Pressure Blocks = 29, Low Pressure Blocks = 103
Nops added 0 bytes to total of 1936 bytes, for 0.00%
Peephole: peephole rules applied: 0
PhaseIdealLoop=7, sum _unique=1744

	at jdk.test.lib.Asserts.fail(Asserts.java:594)
	at jdk.test.lib.Asserts.assertNotEquals(Asserts.java:394)
	at jdk.test.lib.Asserts.assertNE(Asserts.java:367)
	at compiler.debug.TestStressCM.main(TestStressCM.java:70)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
	at java.base/java.lang.Thread.run(Thread.java:832)

JavaTest Message: Test threw exception: java.lang.RuntimeException
JavaTest Message: shutting down test

Normally a Tier2 failure would start out at P3, but this test
failure appears to be generating two sightings on linux-aarch64
per Tier2 job set starting with jdk-16+20-1053-tier2. That's a bit
noisy so I'm starting this bug off as a P2.
Comments
Changeset: b509e31e Author: Roberto Casta��eda Lozano <roberto.castaneda.lozano@oracle.com> Committer: Tobias Hartmann <thartmann@openjdk.org> Date: 2020-10-14 08:07:59 +0000 URL: https://git.openjdk.java.net/jdk/commit/b509e31e
14-10-2020

Does not seem to be aarch64 specific, removing CPU/OS.
13-10-2020

ILW = C2 stress option does not work as expected (test bug), single test on aarch64, no workaround = MLH = P4
13-10-2020

It seems on Aarch64 small sum() method is compiled the same way with different seeds. It could be that in this case the code which checks StressLCM is executed the same way with this flag on and off. And it may be Aarch64 specific. For now [~dcubed] an suggested to put this new test on Problem list so that [~rcastanedalo] can work on it without rush.
12-10-2020

Looks like the failing test, compiler/debug/TestStressCM.java, is new as of this fix: JDK-8253765 C2: Control randomization in StressLCM and StressGCM So far the test failure has only been seen on linux-aarch64.
12-10-2020