The following test failed in the JDK16 CI:

applications/dacapo/Dacapo24H.java

Here's a snippet from the log file:

DacapoRunner: java.awt.Toolkit.getDefaultToolkit(): sun.awt.HeadlessToolkit@4420782a
DacapoRunner: javax.xml.transform.TransformerFactory.newInstance(): com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl@3d7c4d4f
DacapoRunner: Started benchmark: jython


The tail of stress stdout is:
For random generator using seed: 510939874330389042
To re-run test with same seed value please add "-Djdk.test.lib.random.seed=510939874330389042" to command line.
Command line: [/opt/mach5/mesos/work_dir/jib-master/install/jdk-16+4-99/linux-x64.jdk/jdk-16/bin/java -jar /opt/mach5/mesos/work_dir/jib-master/download/org/dacapo/309e1fa/dacapo-309e1fa.jar -l]
[2020-07-01T13:33:12.373460985Z] Gathering output for process 7557
[2020-07-01T13:33:12.457354481Z] Waiting for completion for process 7557
[2020-07-01T13:33:12.457528089Z] Waiting for completion finished for process 7557
Output and diagnostic info for process 7557 was saved into 'pid-7557-output.log'
avrora batik biojava cassandra eclipse fop graphchi h2 h2o jme jython kafka luindex lusearch pmd sunflow tomcat tradebeans tradesoap xalan zxing
--------------------------------------------------------------------------------
IMPORTANT NOTICE:  This is NOT a release build of the DaCapo suite.
Since it is not an official release of the DaCapo suite, care must be taken when
using the suite, and any use of the build must be sure to note that it is not an
offical release, and should note the relevant git hash.

Feedback is greatly appreciated.   The preferred mode of feedback is via github.
Please use our github page to create an issue or a pull request.
    https://github.com/dacapobench/dacapobench.
--------------------------------------------------------------------------------


Stress process main method is started.
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (macroAssembler_x86.cpp:880), pid=7518, tid=7600
#  fatal error: DEBUG MESSAGE: illegal bytecode sequence - method not verified
#
# JRE version: Java(TM) SE Runtime Environment (16.0+4) (build 16-ea+4-99)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (16-ea+4-99, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xa3114d]  MacroAssembler::debug64(char*, long, long*)+0x3d
#
# Core dump will be written. Default location: Core dumps may be processed with "/opt/core.sh %p" (or dumping to /opt/mach5/mesos/work_dir/slaves/4728e7c1-7e67-490e-be0f-6bbf2a2f33db-S171/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/4feb1d45-e894-473e-84d4-36afbdcfb2ab/runs/93448af1-6652-41fb-b44a-ab81f5d587b8/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_dacapo_Dacapo24H_java/scratch/0/core.7518)
#
Unsupported internal testing APIs have been used.

# An error report file with more information is saved as:
# /opt/mach5/mesos/work_dir/slaves/4728e7c1-7e67-490e-be0f-6bbf2a2f33db-S171/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/4feb1d45-e894-473e-84d4-36afbdcfb2ab/runs/93448af1-6652-41fb-b44a-ab81f5d587b8/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_dacapo_Dacapo24H_java/scratch/0/hs_err_pid7518.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
----------System.err:(138/13980)----------


Here's the crashing thread's stack:

---------------  T H R E A D  ---------------

Current thread (0x00007f5d0c005e30):  GCTaskThread "GC Thread#5" [stack: 0x00007f5cb33f1000,0x00007f5cb34f1000] [id=7600]

Stack: [0x00007f5cb33f1000,0x00007f5cb34f1000],  sp=0x00007f5cb34efac0,  free space=1018k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xa3114d]  MacroAssembler::debug64(char*, long, long*)+0x3d

[error occurred during error reporting (printing native stack), id 0xb, SIGSEGV (0xb) at pc=0x00007f5d6f2fa384]


Since this test run crashed in a GC thread, I'm starting this
bug off in hotspot/gc. I'm puzzled why in the world a GC
thread would be calling MacroAssembler::debug64().