JDK-8222445 : [AOT] java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java times out
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 13,14,15,16
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows
  • CPU: x86_64
  • Submitted: 2019-04-15
  • Updated: 2021-03-30
  • Resolved: 2021-03-30
Related Reports
Relates :  
JDK-8246354 - java/lang tests timeout in tier6-comp-aot
Relates :  
JDK-8226309 - [AOT] java/lang/reflect/PublicMethods/PublicMethodsTest.java timed out
Sub Tasks
JDK-8225305 :  
ProblemList java/lang/invoke/VarHandles tests - Resolved
Description
java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java fails with time out.
See:
......
test result: Error. Program `c:\ade\mesos\work_dir\jib-master\install\jdk13-jdk.838\windows-x64-debug.jdk\jdk-13\fastdebug\bin\java' timed out (timeout set to 480000ms, elapsed time including timeout handling was 529453ms).

See full log in comment.
Comments
WNF due to AOT being removed from Oracle JDK builds: JDK-8255616 Note, these issues are for Windows for which AOT was never officially supported.
19-11-2020
No need to rush. I simple looked on it today because an other similar bug was filed JDK-8226309.
20-06-2019
I suppose it's possible that lookup is slower on Windows due to anti virus and address space randomization. Since this test passes (although slowly) and we're not even supporting AOT on Windows in JDK13, I thought this issue could wait a bit. I'll look a it as part of JDK14 work. The next thing I'd like to try is to run this test with a product build to see if the performance problem is primarily caused by assert overhead.
20-06-2019
AOT compilation should not do anything special on Windows. Is it possible that os::dll_lookup() on windows is more expensive? That is how AOT look for classes data during execution.
20-06-2019
Is AOT inlining disabled on Windows? Remember that this is with a fastdebug with asserts enabled.
18-06-2019
+20min with AOT is ridiculous. It should be faster not slower. Something wrong is going on here.
18-06-2019
The test takes 10MIN without AOT.
14-06-2019
Does the execution of the test itself without AOT take a similar amount of time?
13-06-2019
This test along with the jaotc of java.base takes a long time, especially when run with a fastdebug VM and using C1 only. I was able to reproduce the timeout and was only able to get the test to pass when I set an unlimited timeout for the test. I'm not sure what a reasonable timeout value might be but this is not a Windows specific issue. Lowering the priority to a P4. --- a/test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java Tue Jun 11 07:31:47 2019 -0400 +++ b/test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java Thu Jun 13 15:11:24 2019 -0400 @@ -24,9 +24,9 @@ /* * @test * @bug 8154556 - * @run testng/othervm -Diters=20000 -XX:TieredStopAtLevel=1 VarHandleTestByteArrayAsShort - * @run testng/othervm -Diters=20000 VarHandleTestByteArrayAsShort - * @run testng/othervm -Diters=20000 -XX:-TieredCompilation VarHandleTestByteArrayAsShort + * @run testng/othervm/timeout=0 -Diters=20000 -XX:TieredStopAtLevel=1 VarHandleTestByteArrayAsShort + * @run testng/othervm/timeout=0 -Diters=20000 VarHandleTestByteArrayAsShort + * @run testng/othervm/timeout=0 -Diters=20000 -XX:-TieredCompilation VarHandleTestByteArrayAsShort */ import org.testng.annotations.DataProvider; I reran the test and recorded the elapsed time on my system. JAOTC took 35MIN to generate java.base.dll The Test itself took 30MIN to run after the java.base.dll was created.
13-06-2019
Are there any logs that I can look at? Has anyone tried running with a huge timeout to confirm that this is just a slowwwww test?
11-06-2019
So, this seems to be very much windows specific (maybe?). I'm not able to reproduce it on other OSes. I run it as: make run-test CONF=macosx-x86_64-server-fastdebug TEST=open/test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java TEST_OPTS_AOT_MODULES="java.base" TEST_VM_OPTS="-ea -esa -XX:TieredStopAtLevel=1" LOG=cmdlines I also added the following change to make jaotc complete in adequate time with TieredStopAtLevel=1: https://github.com/oracle/graal/commit/cdb49b8be874a8dedcf2048e1fb12ed791920915 It's not in the JDK repo yet, so it may need to be patched manually. [~bobv] Could you please try reproducing it on Windows? Thanks a lot!
10-06-2019
Bob, could you please try to reproduce this on windows?
10-06-2019
Could be related to JDK-8223533.
04-06-2019
May be this tests are patalogical for AOT and we should not run them even in Tiered mode.
31-05-2019
[~iveresov] I assigning this to you. I think for now we should just do workaround - modify tests to not run AOTed java.base and Graal without tiered mode. java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java
31-05-2019
Something like next for all 3 tests: test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java @@ -24,8 +24,12 @@ /* * @test * @bug 8154556 + * @run testng/othervm -Diters=20000 VarHandleTestByteArrayAsShort + */ +/* + * @test + * @requires !vm.graal.enabled & !vm.aot.enabled * @run testng/othervm -Diters=20000 -XX:TieredStopAtLevel=1 VarHandleTestByteArrayAsShort - * @run testng/othervm -Diters=20000 VarHandleTestByteArrayAsShort * @run testng/othervm -Diters=20000 -XX:-TieredCompilation VarHandleTestByteArrayAsShort */
31-05-2019
I think we���ll use AOT methods regardless of the TieredStopAtLevel value.
31-05-2019
I would suggest to split testing into to parts to run with Graal or AOT only with default flags. Like David H. did for JDK-8222292.
31-05-2019
java.base.so was not compiled for tiered so it should be fine to use it: jaotc -J-Xmx4g --info -J-server -J-ea -J-esa --compile-commands test/hotspot/jtreg/compiler/aot/scripts/java.base-list.txt --linker-path VC/bin/x64/link.exe --compile-with-assertions --output java.base.dll --module java.base Note, some testing shows that running VarHandleTestAccessBoolean.java test with -Xint and java.base.so passed but it timeout with -XX:TieredStopAtLevel=1.
31-05-2019
test run in 3 modes: * @run testng/othervm -Diters=20000 -XX:TieredStopAtLevel=1 VarHandleTestByteArrayAsChar * @run testng/othervm -Diters=20000 VarHandleTestByteArrayAsChar * @run testng/othervm -Diters=20000 -XX:-TieredCompilation VarHandleTestByteArrayAsChar We should run with Graal only 2nd form. With AOTed java.base we failed with 1st form. [~iveresov] what happens when TieredStopAtLevel=1 is set and we have aot methods?
31-05-2019
[~kvn] Please consider doing something about this for JDK 13 (at a minimum least problem list the tests in question).
31-05-2019
Why are we running AOT testing on Windows? -- It only pollutes the pipeline and creates a lot of noise.
28-05-2019
Please note that we are not supporting AOT on Windows yet (we do run tests). And AOT is low priority for us. I am changing 'Fix version' to 'tbd'.
13-05-2019
Vladimir, could you please have a look or re-assign? Thanks.
18-04-2019
ILW = Test times out, intermittent at tier6 (with AOT), no workaround (but disable AOT) = MMH = P3
18-04-2019
All failures happened with AOT enabled, moving to compiler team.
18-04-2019
[~stefank] Done.
17-04-2019