JDK-8288445 : AArch64: C2 compilation fails with guarantee(!true || (true && (shift != 0))) failed: impossible encoding
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,17,19,20
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: aarch64
  • Submitted: 2022-06-14
  • Updated: 2022-10-20
  • Resolved: 2022-06-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 JDK 17 JDK 19 JDK 20
11.0.18-oracleFixed 17.0.6-oracleFixed 19 b29Fixed 20Fixed
Related Reports
Relates :  
JDK-8288903 - ShouldNotReachHere() in Type::typerr() after 8284960
Description
The following closed test failed in the JDK20 CI:

applications/javafuzzer/QuickTest.java

Here's a snippet from the log file:

----------System.out:(28/1898)----------
Using JRuby executable: /opt/mach5/mesos/work_dir/jib-master/install/org/jruby/jruby-dist/9.2.12.0/jruby-dist-9.2.12.0-bin.zip/jruby-9.2.12.0/bin/jruby
For random generator using seed: 1836776624702845882
To re-run test with same seed value please add "-Djdk.test.lib.random.seed=1836776624702845882" to command line.
Starting JavaFuzzer: '/bin/bash /opt/mach5/mesos/work_dir/jib-master/install/com/oracle/jpg/bigapps/javafuzzer/javafuzzer/1.0/javafuzzer-1.0.zip/mrt.sh -R /opt/mach5/mesos/work_dir/slaves/779adf21-f3e5-4e6a-a889-8cc0f9bc6fbb-S68623/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ff1f6331-4cab-4e5a-8513-ab7268af1b5a/runs/af1e2b33-b4de-4373-923b-75ed567a30d1/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_javafuzzer_QuickTest_java/scratch/0 -NT 1 -NP 4 -A -conf config.yml'
[2022-06-14T17:45:11.502262125Z] Gathering output for process 3930046
[2022-06-14T17:46:44.995065590Z] Waiting for completion for process 3930046
[2022-06-14T17:46:44.995283510Z] Waiting for completion finished for process 3930046
Output and diagnostic info for process 3930046 was saved into 'pid-3930046-output.log'

Summary of the JavaFuzzer run:
------------------------------
Host:     ol8-aarch64-285398
Tests:    4 x 1
Args:     -conf config.yml

Started  at: Tue Jun 14 17:45:11 UTC 2022


r2- 1: 1 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 0 Reference Java failures
r3- 1: 1 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 0 Reference Java failures
r4- 1: 0 passed, 2 crashes, 0 fails, 0 hangs, 0 incorrect tests, 0 Reference Java failures
r1- 1: 0 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 1 Reference Java failures

Finished at: Tue Jun 14 17:46:44 UTC 2022


[2022-06-14T17:46:45.000326319Z] Waiting for completion for process 3930046
[2022-06-14T17:46:45.000414119Z] Waiting for completion finished for process 3930046
----------System.err:(13/728)----------
java.lang.RuntimeException: assertEquals: expected 1 to equal 2
	at jdk.test.lib.Asserts.fail(Asserts.java:594)
	at jdk.test.lib.Asserts.assertEquals(Asserts.java:205)
	at jdk.test.lib.Asserts.assertEquals(Asserts.java:189)
	at applications.javafuzzer.JavaFuzzerRunner.main(JavaFuzzerRunner.java:235)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
	at java.base/java.lang.Thread.run(Thread.java:1596)

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

result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: assertEquals: expected 1 to equal 2


This assertion failure mode matches the following closed bug:

JDK-8286305 loom: closed applications/javafuzzer/QuickTest.java fails "assertEquals: expected 1 to equal 2":

However, that bug is closed as a duplicate of:

JDK-8286182 [BACKOUT] x86: Handle integral division overflow during parsing

which is specific to x86 and this failure sighting is on linux-aarch64.
Comments
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/1462 Date: 2022-10-18 16:05:28 +0000
18-10-2022
Fix Request (11u) Not a clean backport, but also not complicated (some of the patched instructions do not exist in 11). The test case passes before and after the change. Backporting to 11 brings parity with Oracle 11.
18-10-2022
Fix Request (17u) On behalf of Yi-Fan Tsai <yftsai@amazon.com>. Critical fix to match Oracle. Clean except for a trivial context difference. Low risk: limits shift counts to positive values.
02-09-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/640 Date: 2022-08-19 18:41:49 +0000
22-08-2022
Both new compiler/codegen/ShiftByZero.java test and Javafuzzer app passed in latest JDK 19b3* CI.
11-07-2022
Changeset: b4490386 Author: Dean Long <dlong@openjdk.org> Date: 2022-06-28 03:12:12 +0000 URL: https://git.openjdk.org/jdk19/commit/b4490386fe348250e88347526172c1c27ef01eba
28-06-2022
I see. Thanks for your explanation. [~thartmann]
21-06-2022
The tests were generated by the JavaFuzzer and it's expected to also generate tests that are long/endless running and hit a timeout (i.e. they "hang"). These can simply be ignored.
21-06-2022
Hi [~dlong], in my local AArch64 machine, "Test-hang" test can finish, but it indeed lasted for a long time, ~30 min. May I ask: 1) How did you define a "hang" bug? The execution time exceeds the expectation a lot, right? I noticed that there are nested loops for "vMeth2" call, and I suspect the expected execution time might be long. 2) It seems not an AArch64 specific issue. Did you test on other platforms? I also ran "Test-hang" on x86-64 machine, and the execution can finish and it lasted long as well. Thanks
21-06-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk19/pull/40 Date: 2022-06-17 22:37:28 +0000
17-06-2022
It seems we don't optimize out shift-by-zero that can result after post-loop optimizations. The back-end needs to guard against this.
16-06-2022
ILW = crash; always with test; no workaround = HMH = P2
14-06-2022
There is also a 2nd problem reported in the fuzzer artifacts: a hang. I have attached this test as "Test-hang".
14-06-2022
# Internal Error (workspace/open/src/hotspot/cpu/aarch64/assembler_aarch64.hpp:2778), pid=3931121, tid=3931134 # guarantee(!true || (true && (shift != 0))) failed: impossible encoding Current CompileTask: C2: 178 13 b Test::bMeth (407 bytes) Stack: [0x0000fffbf5800000,0x0000fffbf5a00000], sp=0x0000fffbf59fa470, free space=2025k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x505ca4] Assembler::ushr(FloatRegisterImpl const*, Assembler::SIMD_Arrangement, FloatRegisterImpl const*, int)+0x154 V [libjvm.so+0x483010] vsrl2L_immNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0xf0 V [libjvm.so+0x162a980] PhaseOutput::scratch_emit_size(Node const*)+0x320 V [libjvm.so+0x1621f24] PhaseOutput::shorten_branches(unsigned int*)+0x2c4 V [libjvm.so+0x1633098] PhaseOutput::Output()+0xbc8 V [libjvm.so+0xa896fc] Compile::Code_Gen()+0x3bc V [libjvm.so+0xa8dbc4] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x10a0 V [libjvm.so+0x8c5760] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1bc V [libjvm.so+0xa9b934] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x874 V [libjvm.so+0xa9c584] CompileBroker::compiler_thread_loop()+0x424 V [libjvm.so+0x1904a84] JavaThread::thread_main_inner()+0x254 V [libjvm.so+0x190f0e8] Thread::call_run()+0xf8 V [libjvm.so+0x160a5a4] thread_native_entry(Thread*)+0x104 C [libpthread.so.0+0x78f8] start_thread+0x188 The assert happens because "shift" is 0.
14-06-2022