-XX:AbortVMOnException=java.lang.NullPointerException

[Tom Rodriguez]

C2 has some gating logic for transforming explicit null tests into implicit null checks but it will certainly do this.  If it happens too often it will recompile the method which should revert to explicit checks.  I suspect if you ran the right program it would fail in the same way for C2.

      implicit_null_check(block, proj, val, allowed_reasons);
      // The implicit_null_check will only perform the transformation
      // if the null branch is truly uncommon, *and* it leads to an
      // uncommon trap.  Combined with the too_many_traps guards
      // above, this prevents SEGV storms reported in 6366351,
      // by recompiling offending methods without this optimization.

There was a bug where a user written null test was converted into an implicit test and never converted back to an explicit test.  null became a common value so every test resulted into signal trapping and deopt which was horrifically slow.

It doesn’t seem like the debug_check_abort code call should be there in the first place since it’s not the actual throw point.  It may be there to deal with the fast throw machinery in C2 since it doesn’t actually create a new exception at the throw point.  That may no longer be an issue though since there’s now some gating machinery on that.  It used to be that it would immediately begin using preallocated exceptions.  Anyway, for graal we could just return target_pc instead of setting it and falling through.  Most of the other cases directly return anyway.

tom

On Jun 20, 2014, at 1:03 AM, Gilles Duboscq <duboscq at ssw.jku.at> wrote:

> I think in the Graal context, when we use implicit exceptions, we
> assume that the exception behaviour is fully handled in the
> interpreter.
> I'll disable the Exceptions::debug_check_abort check in the "deopt on
> implicit exception" case.
> 
> That's interesting because it means that C2 never uses an implicit
> null check speculatively?
> 
> -Gilles
> 
> On Fri, Jun 20, 2014 at 5:54 AM, Tom Deneau <tom.deneau at amd.com> wrote:
>> I wanted to use the option  -XX:AbortVMOnException=java.lang.NullPointerException to try to solve a different problem but I noticed when I use it, I always get this NullPointerException from LinearScanWalker showing up.  Is this expected?
>> 
>> (This was with the fastdebug build).
>> 
>> -- Tom
>> 
>> Stack: [0x00002b123e9d5000,0x00002b123ead6000],  sp=0x00002b123ead1b80,  free space=1010k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x1006d88]  VMError::report_and_die()+0x168
>> V  [libjvm.so+0x6ececf]  report_fatal(char const*, int, char const*)+0x6f
>> V  [libjvm.so+0x7a6ed1]  Exceptions::debug_check_abort(char const*, char const*)+0x91
>> V  [libjvm.so+0xe8ef70]  SharedRuntime::continuation_for_implicit_exception(JavaThread*, unsigned char*, SharedRuntime::ImplicitExceptionKind)+0x1a0
>> V  [libjvm.so+0xd766a1]  JVM_handle_linux_signal+0x5d1
>> V  [libjvm.so+0xd64832]  signalHandler(int, siginfo_t*, void*)+0x42
>> C  [libc.so.6+0x36ff0]  killpg+0x40
>> j  com.oracle.graal.compiler.alloc.LinearScanWalker.activateCurrent(Lcom/oracle/graal/compiler/alloc/Interval;)Z+92
>> j  com.oracle.graal.compiler.alloc.IntervalWalker.walkTo(I)V+88
>> j  com.oracle.graal.compiler.alloc.OptimizingLinearScanWalker.walk()V+191
>> j  com.oracle.graal.compiler.alloc.LinearScan.allocateRegisters()V+80
>> j  com.oracle.graal.compiler.alloc.LinearScan.allocate()V+163
>> j  com.oracle.graal.compiler.GraalCompiler.emitLIR(Lcom/oracle/graal/compiler/target/Backend;Lcom/oracle/graal/api/code/TargetDescription;Lcom/oracle/graal/phases/schedule/SchedulePhase;Lcom/oracle/graal/nodes/StructuredGraph;Ljava/lang/Object;Lcom/oracle/graal/api/code/CallingConvention;Lcom/oracle/graal/api/code/RegisterConfig;)Lcom/oracle/graal/lir/gen/LIRGenerationResult;+618
>> j  com.oracle.graal.compiler.GraalCompiler.emitBackEnd(Lcom/oracle/graal/nodes/StructuredGraph;Ljava/lang/Object;Lcom/oracle/graal/api/code/CallingConvention;Lcom/oracle/graal/api/meta/ResolvedJavaMethod;Lcom/oracle/graal/compiler/target/Backend;Lcom/oracle/graal/api/code/TargetDescription;Lcom/oracle/graal/api/code/CompilationResult;Lcom/oracle/graal/lir/asm/CompilationResultBuilderFactory;Lcom/oracle/graal/api/code/Assumptions;Lcom/oracle/graal/phases/schedule/SchedulePhase;Lcom/oracle/graal/api/code/RegisterConfig;)V+27
>> j  com.oracle.graal.compiler.GraalCompiler.compileGraph(Lcom/oracle/graal/nodes/StructuredGraph;Ljava/lang/Object;Lcom/oracle/graal/api/code/CallingConvention;Lcom/oracle/graal/api/meta/ResolvedJavaMethod;Lcom/oracle/graal/phases/util/Providers;Lcom/oracle/graal/compiler/target/Backend;Lcom/oracle/graal/api/code/TargetDescription;Ljava/util/Map;Lcom/oracle/graal/phases/PhaseSuite;Lcom/oracle/graal/phases/OptimisticOptimizations;Lcom/oracle/graal/api/meta/ProfilingInfo;Lcom/oracle/graal/api/code/SpeculationLog;Lcom/oracle/graal/phases/tiers/Suites;Lcom/oracle/graal/api/code/CompilationResult;Lcom/oracle/graal/lir/asm/CompilationResultBuilderFactory;)Lcom/oracle/graal/api/code/CompilationResult;+99
>> j  com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.compileKernel(Lcom/oracle/graal/api/meta/ResolvedJavaMethod;Z)Lcom/oracle/graal/gpu/ExternalCompilationResult;+161