sh/jdk fails with Serial

Aleksey Shipilev shade at redhat.com
Thu Nov 29 22:27:02 UTC 2018


Run latest sh/jdk with:

$ linux-x86_64-server-fastdebug/images/jdk/bin/java  \
 -jar target/benchmarks.jar Serial -foe true -f 10 -wi 5 -i 5 -t 1 -w 1s -r 1s   \
 --jvmArgs '-Xmx1g -Xms1g -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC  \
            -XX:+UnlockDiagnosticVMOptions -XX:ShenandoahGCHeuristics=aggressive \
            -XX:+ShenandoahVerifyOptoBarriers -XX:+ShenandoahOOMDuringEvacALot'

It would fail with:

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error
(/home/shade/trunks/shenandoah-jdk/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp:3992),
pid=6669, tid=6681
#  assert(!uu->is_MergeMem()) failed: chain of MergeMems?
#
# JRE version: OpenJDK Runtime Environment (12.0) (fastdebug build
12-internal+0-adhoc.shade.shenandoah-jdk)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 12-internal+0-adhoc.shade.shenandoah-jdk, mixed mode,
sharing, tiered, compressed oops, shenandoah gc, linux-amd64)
# Core dump will be written. Default location: Core dumps may be processed with
"/usr/share/apport/apport %p %s %c %d %P" (or dumping to
/home/shade/projects/redhat-benchmarks/core.6669)
#
# An error report file with more information is saved as:
# /home/shade/projects/redhat-benchmarks/hs_err_pid6669.log
#
# Compiler replay data is saved as:
# /home/shade/projects/redhat-benchmarks/replay_pid6669.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

Stack: [0x00007f6c841b0000,0x00007f6c842b1000],  sp=0x00007f6c842a9580,  free space=997k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native
code)
V  [libjvm.so+0x1a6e6b0]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*,
Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x310
V  [libjvm.so+0x1a6f50f]  VMError::report_and_die(Thread*, void*, char const*, int, char const*,
char const*, __va_list_tag*)+0x2f
V  [libjvm.so+0xb2d56a]  report_vm_error(char const*, int, char const*, char const*, ...)+0x12a
V  [libjvm.so+0x17f8f2b]  MemoryGraphFixer::fix_mem(Node*, Node*, Node*, Node*, Node*,
Unique_Node_List&) [clone .constprop.189]+0xf8b
V  [libjvm.so+0x17fdea9]  ShenandoahWriteBarrierNode::pin_and_expand(PhaseIdealLoop*)+0x3129
V  [libjvm.so+0x1744c6c]  ShenandoahBarrierSetC2::optimize_loops(PhaseIdealLoop*, LoopOptsMode,
VectorSet&, Node_Stack&, Node_List&) const+0x19c

Bisect would show the cause is:

The first bad revision is:
changeset:   53594:2fff3e3b8015
user:        roland
date:        Thu Nov 29 15:12:20 2018 +0100
summary:     more gc interface loop opts


Thanks



More information about the shenandoah-dev mailing list