JDK-8198915 : [Graal] 3rd testcase of compiler/types/TestMeetIncompatibleInterfaceArrays.java takes more than 10 mins
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10,11
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-03-01
  • Updated: 2018-04-19
  • Resolved: 2018-03-28
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 11
11 b10Fixed
Related Reports
Relates :  
Relates :  
Description
3rd testcase of compiler/types/TestMeetIncompatibleInterfaceArrays.java takes more than 10 mins when running with Graal as JIT. As result the test could fail by timeout.

Here results of running the test on my linux machine:
  build: 6.267 seconds
  compile: 6.261 seconds
  build: 4.899 seconds
  compile: 4.897 seconds
  driver: 0.456 seconds
  build: 4.876 seconds
  compile: 4.875 seconds
1st  main: 7.55 seconds
  build: 0.001 seconds
2nd  main: 12.099 seconds
  build: 0.0 seconds
3rd  main: 758.013 seconds
Comments
Yes, that seems more like it :) Thanks Vladimir!
29-03-2018

I think it is JDK-8200360 which was fixed today only.
29-03-2018

In the Wednesday nightly I see several failures of the kind: java.lang.Exception: Method public static compiler.types.TestMeetIncompatibleInterfaceArrays$I1 MeetIncompatibleInterfaceArrays0ASM.run() must be compiled at tier 0 ! at compiler.types.TestMeetIncompatibleInterfaceArrays.main(TestMeetIncompatibleInterfaceArrays.java:382) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:569) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:841) Was that due to this bug?
29-03-2018

Thanks, Volker!
27-03-2018

Hi [~thartmann], the intention of the test was to have a method which is invoked three times: the first time interpreted, the second time compiled with C1 and the third time compiled with C2. I don't remember if the WB API wasn't available at the time I wrote the test or if I just thought the test setup would be simpler this way. Anyway, I try to rewrite the test to use the WB API instead.
26-03-2018

The problem is that the test sets -XX:Tier0InvokeNotifyFreqLog=0 which causes the interpreter to call InterpreterRuntime::frequency_counter_overflow() at every single method invocation. This is more or less fine when the test is being executed with C2 because not too many Java methods are executed. However, if Graal is used as JIT, a large number of (Graal) Java methods are executed and due to Tier0InvokeNotifyFreqLog=0, execution is extremely slow. Running the following command takes 1.7s on my machine: java -Xbatch -XX:CompileCommand=compileonly,does.not::exist -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.Compiler=graal -version Running with -XX:Tier0InvokeNotifyFreqLog=0 takes 29s (due to JVMCI initialization force by -Xbatch being very slow): java -Xbatch -XX:CompileCommand=compileonly,does.not::exist -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.Compiler=graal -XX:Tier0InvokeNotifyFreqLog=0 -version I wonder why setting Tier0InvokeNotifyFreqLog=0 is necessary. One could just trigger compilation with the WhiteBox API. [~simonis], you added the test with JDK-8141551. Do you remember? ILW = Test times out (or is very slow), single test with Graal as JIT, no workaround = MLH = P4
02-03-2018

Compiler team, could you please evaluate whether this is reasonable behavior for Graal or not. Steps to run the test: > jtreg -timeoutFactor:10 -vt -jdk:JDK_HS_fastdebug -vmoptions:-XX:MaxRAMPercentage=8 -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.Compiler=graal compiler/types/TestMeetIncompatibleInterfaceArrays.java
01-03-2018