C1 crash in LinearScan::eliminate_spill_moves

[Tobias Hartmann]

Hi Eirik,

thanks for reporting this issue. Could you provide the instrumented .class file and the
replay_pid*.log file that should have been generated by the crashing VM?

Thanks,
Tobias

On 05.02.21 10:51, Eirik Bjørsnøs wrote:
> Hi,
> 
> While developing a Java agent which does some instrumentation, I'm
> observing the following C1 compilation crash quite reliably on 11, 15 and
> 17:
> 
> 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]
>  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x5b2
> 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,
> BasicType)+0x132
> V  [libjvm.dylib+0x4692a7]  MoveResolver::insert_move(Interval*,
> Interval*)+0x1e7
> V  [libjvm.dylib+0x469800]  MoveResolver::resolve_mappings()+0x250
> V  [libjvm.dylib+0x469f02]  MoveResolver::move_insert_position(LIR_List*,
> int)+0x72
> V  [libjvm.dylib+0x46d40b]  LinearScanWalker::insert_move(int, Interval*,
> Interval*)+0x26b
> 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.
> 
> Cheers,
> Eirik.
> 
> [1]
> https://github.com/jenkinsci/jaxen/blob/V_1_1_6_Final/src/java/main/org/jaxen/saxpath/base/Verifier.java#L95
>