As part of JVMCI (JDK-8136421), HotSpot hs-err log files now include a disassembly of a crashing CodeBlob if a hsdis-based disassembler is available as a dynamic loaded library. While this is common in development scenarios, it's not so in product JDK distributions. In that case, all that one gets is the "Instructions" block of raw bytes around the program counter.

To improve this, the abstract assembly dumping added by JDK-8213084 can be used to improve the content of hs-err logs.

In addition to the machine code for the crashing method/frame, it is often useful to also have the machine code for frames/methods further up the stack. For example, consider the following excerpt from a hs-err log:

--------
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (synchronizer.cpp:1543), pid=414762, tid=427493
# guarantee(mark->is_neutral()) failed: mark in 0x000000173af671e0is not neutral 0x00007f2f887a4005
#

Stack: [0x00007f2483545000,0x00007f2483646000], sp=0x00007f2483640180, free space=1004k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0xe91074] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x354
V [libjvm.so+0xe91c8f] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x2f
V [libjvm.so+0x68f516] report_vm_error(char const*, int, char const*, char const*, ...)+0x106
V [libjvm.so+0xde5a54] ObjectSynchronizer::slow_exit(oopDesc*, BasicLock*, Thread*)+0x294
V [libjvm.so+0xd4a025] SharedRuntime::monitor_exit_helper(oopDesc*, BasicLock*, JavaThread*, bool)+0x65

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v ~RuntimeStub::Stub<monitorexit(Object,Word)void>
J 1060456 jvmci org.mozilla.javascript.RhinoException.printStackTrace(Ljava/io/PrintWriter;)V (24 bytes) @ 0x00007f3b4591556b [0x00007f3b4590e7c0+0x0000000000006dab]
--------

Having the disassembly for the RhinoException.printStackTrace might provide valuable insight as to why the mark word was in an invalid state when calling out to the monitorexit slow path stub.

A sample of an enhanced hs-err log can be seen in the hs_err_pid7179.log file attached to this issue.