Bug ID: JDK-8225653 Provide more information when hitting SIGILL from HaltNode

Versions (Unresolved/Resolved/Fixed)

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 13	JDK 14
11.0.10-oracleFixed	13.0.4Fixed	14 b14Fixed

There are existing usages of Halt for optimizing unsafe accesses (e.g., GraphKit::must_be_not_null), but, as a future enhancement, it would be nice to provide more information about the root cause of the crash. As an example, JDK-8219902 [1] which involved Halt execution manifested as:

   # SIGILL (0x4) at pc=0x00007f55b4df37d6, pid=15865, tid=15869
   #
   # JRE version: OpenJDK Runtime Environment (13.0+9) (build 13-ea+9)
   # Java VM: OpenJDK 64-Bit Server VM (13-ea+9, mixed mode, sharing, 
tiered, compressed oops, g1 gc, linux-amd64)
   # Problematic frame:
   # J 10152 c2 
com.sun.tools.javac.tree.Pretty.visitLiteral(Lcom/sun/tools/javac/tree/JCTree$JCLiteral;)V 
jdk.compiler at 13-ea (282 bytes) @ 0x00007f55b4df37d6 
[0x00007f55b4df07a0+0x0000000000003036]

Without laborous analysis of generated code, it's impossible to say 
whether it's a JVM bug or a problem in user code. I believe JVM can do better in such situations and print meaningful error message instead when crashing.

http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-June/034194.html

Fix request (13u): I would like to backport this fix to 13u for parity with 11u. The original change applies cleanly. Followup fixes for JDK-8231720 and JDK-8022574 are requested as well.
08-06-2020
Will do. The backport patch for JDK-8022574 is clean except for a minor adaptation of the hunk for arm.ad due to the Oracle arm64 port still being in 11u. See http://cr.openjdk.java.net/~phh/8022574/webrev.11u.00/ I've posted a review request and will tag JDK-8022574 with jdk11u-fix-request as soon as it's reviewed.
23-05-2020
Hi ~phh, will you also request JDK-8022574 and push them in one go? I don't see the jdk11u-fix-request label there. Cheers Christoph
23-05-2020
Fix Request (11u). Patch is worth doing to enhance diagnostics, applies cleanly, affects hs_err diagnostic only. The patch did, however, introduce a performance issue by generating stop() after uncommon traps rather than a single instruction (e.g., "ud2" on x86). stop() is a runtime call and thus takes up a lot of icache space to no purpose when it occurs after an uncommon trap. This backport thus needs two further backports that fix that. The first is JDK-8231720 and the second JDK-8022574.
22-05-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/fafba5cf3546 User: thartmann Date: 2019-09-10 06:49:09 +0000
10-09-2019
http://cr.openjdk.java.net/~chagedorn/8225653/webrev.02/
09-09-2019

Relates :	JDK-8224658 - Unsafe access C2 compile fails with assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr: adr_type = NULL
Relates :	JDK-8230762 - Change MacroAssembler::debug32/64 to use fatal instead of assert
Relates :	JDK-8231430 - C2: Memory stomp in max_array_length() for T_ILLEGAL type
Relates :	JDK-8230552 - Provide information when hitting a HaltNode for architectures other than x86
Relates :	JDK-8260338 - Some fields in HaltNode is not cloned
Relates :	JDK-8229495 - SIGILL in C2 generated OSR compilation
Relates :	JDK-8231720 - Some perf regressions after 8225653