JDK-8224254 : compiler/graalunit/HotspotJdk9Test.java is timing out intermittently
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 13
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2019-05-20
  • Updated: 2019-07-17
  • Resolved: 2019-06-12
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 13 JDK 14
13Fixed 14 b05Resolved
Related Reports
Duplicate :  
JDK-8225497 - Update Graal
Relates :  
JDK-8225655 - Remove compiler/graalunit/HotspotJdk9Test.java from the ProblemList
Sub Tasks
JDK-8224715 :  
ProblemList compiler/graalunit/HotspotJdk9Test.java - Resolved
Description
compiler/graalunit/HotspotJdk9Test.java is timing out intermittently in tier 3 after the Graal integration in JDK-8223346.

The timeout is first seen in my first pre-integration mach5 test on the 14th. In this case the test is in tier 8 and due to other noise in tier 8 it was not noticed.

It's then seen in the Graal nightly in tier 3 on the 15:th.

Again in tier 8 in my second mach5 pre-integration test on the 16:th.
After that I integrated Graal, and it started happening in various peoples tier 3 runs and in the CI.
Comments
I'm closing this as duplicate of the Graal Update (JDK-8223807) which will include the fix and filed JDK-8225655 to remove the test from the problem list.
12-06-2019
https://github.com/oracle/graal/commit/74577222e12f8a7694a84372e81cf51ba0bf79fe We will get this fix with the next Graal Update (JDK-8223807) and should then remove the test from the ProblemList.
07-06-2019
Thank you for your excellent analysis! Good job!
31-05-2019
Graal relies on JVM's UseFMA flag. When the target machine does not support FMA, UseFMA is off, and Graal will compile the original Java implementation instead. In JDK, Math.fma(FFF) turns float into double and then perform the multiple-add operation; while Math.fma(DDD) has to instantiate multiple BigDecimal, perform the multiple-add operation on BigDecimal, and then use Double.parseDouble(BigDecimal.toString()) to generate the double result. The last step is extremely time-consuming. I tested on my machine. In such a case, Graal decided not to inline the Math.fma(DDD) callsite in the test snippet, and the compiled code will be simply an invocation. Likely we end up interpreting the Math.fma(DDD) method 1728 times. I will make a PR bypassing this test case when UseFMA is off.
31-05-2019
Looking on supported instructions on testing machine and it does not have FMA support: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx pdpe1gb rdtscp lm constant tsc rep good nopl eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4 1 sse4 2 x2apic popcnt tsc deadline timer aes xsave avx hypervisor lahf lm xsaveopt ibrs stibp ibpb pti Looking on MathDoubleFMATest,java and it has 1728 combinations to to run. I am not sure what Graal generates when FMA is not supported by CPU. But still MathDoubleFMATest should not take so long to execute comparing to similar test MathFloatFMATest. Note, testing ran with java assertions: '-ea -esa -server -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:-UseJVMCICompiler' [~yzheng] Please, look.
29-05-2019
10 longest running test classes: 1,017,430 ms org.graalvm.compiler.hotspot.jdk9.test.MathDoubleFMATest 7,603 ms org.graalvm.compiler.hotspot.jdk9.test.MathFloatFMATest 4,030 ms org.graalvm.compiler.hotspot.jdk9.test.StringUTF16ToBytesGetCharsTest 716 ms org.graalvm.compiler.hotspot.jdk9.test.MathFMAConstantInputTest
24-05-2019
There are similar failures in: compiler/graalunit/JttReflectFieldGetTest.java compiler/graalunit/HotspotTest.java compiler/graalunit/CoreTest.java Unclear if these are related. They ran on the same host so could be that they were dos:ed out if HotspotJdk9Test.java consumed all CPU or similar.
24-05-2019