C1 crash in LinearScan::eliminate_spill_moves

Eirik Bjørsnøs eirbjo at gmail.com
Fri Feb 5 09:51:33 UTC 2021


While developing a Java agent which does some instrumentation, I'm
observing the following C1 compilation crash quite reliably on 11, 15 and

Current CompileTask:
C1:   1468  434   !   3       org.jaxen.saxpath.base.Verifier::isXMLLetter
(7201 bytes)

Stack: [0x000070000f92d000,0x000070000fa2d000],  sp=0x000070000fa2c3e0,
 free space=1020k
Native frames: (J=compiled Java code, A=aot compiled Java code,
j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x1fb1d0]  LinearScan::eliminate_spill_moves()+0x230
V  [libjvm.dylib+0x203ae0]  LinearScan::do_linear_scan()+0xc0
V  [libjvm.dylib+0x197093]  Compilation::emit_lir()+0x213
V  [libjvm.dylib+0x197dee]  Compilation::compile_java_method()+0x29e
V  [libjvm.dylib+0x1980cc]  Compilation::compile_method()+0x11c
V  [libjvm.dylib+0x1984ee]  Compilation::Compilation(AbstractCompiler*,
ciEnv*, ciMethod*, int, BufferBlob*, DirectiveSet*)+0x22e
V  [libjvm.dylib+0x199bde]  Compiler::compile_method(ciEnv*, ciMethod*,
int, DirectiveSet*)+0x5e
V  [libjvm.dylib+0x2d8292]
V  [libjvm.dylib+0x2d7bb2]  CompileBroker::compiler_thread_loop()+0x4c2

With a Java 17 fastdebug build, I observe this assertion fail:

V  [libjvm.dylib+0x123e8dd]  VMError::report_and_die(int, char const*, char
const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*,
int, unsigned long)+0x6cd
V  [libjvm.dylib+0x123eefb]  VMError::report_and_die(Thread*, void*, char
const*, int, char const*, char const*, __va_list_tag*)+0x3b
V  [libjvm.dylib+0x62a7ad]  report_vm_error(char const*, int, char const*,
char const*, ...)+0xdd
V  [libjvm.dylib+0x42c132]  LIR_OprFact::virtual_register(int,
V  [libjvm.dylib+0x4692a7]  MoveResolver::insert_move(Interval*,
V  [libjvm.dylib+0x469800]  MoveResolver::resolve_mappings()+0x250
V  [libjvm.dylib+0x469f02]  MoveResolver::move_insert_position(LIR_List*,
V  [libjvm.dylib+0x46d40b]  LinearScanWalker::insert_move(int, Interval*,
V  [libjvm.dylib+0x470ba1]  LinearScanWalker::activate_current()+0x371
V  [libjvm.dylib+0x46c682]  IntervalWalker::walk_to(int)+0xe2
V  [libjvm.dylib+0x45963d]  LinearScan::allocate_registers()+0x4ad
V  [libjvm.dylib+0x46298d]  LinearScan::do_linear_scan()+0x46d
V  [libjvm.dylib+0x3c2630]  Compilation::emit_lir()+0x150
V  [libjvm.dylib+0x3c3694]  Compilation::compile_java_method()+0x344

Some context:

As seen in the Java source file [1] for the class, the uninstrumented
method is quite large and has an unusual number of returns per instruction.

The agent is basically a code coverage instrumenter which inserts a local
variable per line of code in the beginning of the method, increments the
count on each line number and reports the total counts by calling methods
in a catch block.

To reduce the amount of instrumented code, the agent also replaces *RETURN
instructions with GOTOs to a common target where the count reporting
happens. The catch handler also jumps to this target.

If I limit the number of code lines which are allowed to be instrumented,
the compilation no longer crashes. So seems to be related to code size /
complexity somehow.

I can provide core files on request.



More information about the hotspot-compiler-dev mailing list