Redundant dereferences in C2 shenandoah_wb?

[Roman Kennke]

The compiler can replace explicit null checks with implicit null checks, and rely on the first instruction of the wb (or any load or store for that matter) blowing a SIGSEGV. I suppose this happens when the compiler figures that null is rare or impossible.

RomanAm 07.09.2016 12:41 nachm. schrieb Aleksey Shipilev <ashipile at redhat.com>:
>
> Wait a minute, can you elaborate the scenario where we want to intercept 
> null there? Because this code: 
>
>     @Benchmark 
>     @CompilerControl(CompilerControl.Mode.DONT_INLINE) 
>     public void storeToNull() { 
>         try { 
>             targetNull.field = null; 
>         } catch (NullPointerException e) { 
>             // expected 
>         } 
>    } 
>
>     static class Target { 
>         Object field; 
>     } 
>
> ...triggers NPE much earlier (look for "WHY THIS CHECK?"): 
> http://cr.openjdk.java.net/~shade/shenandoah/wb.deref.1/storeToNull.perfasm 
>
> How could that check fire a SEGV, if we already tested %r11 is not null? 
> I assume this is universal, and we nullcheck before doing shenandoahWB code? 
>
> Thanks, 
> -Aleksey 
>
> On 09/07/2016 01:10 PM, Roman Kennke wrote: 
> > The first is only there to trigger a SIGSEGV/NPE on null. The 2nd 
> > absolutely needs to come after the check for evacuation in progress 
> > to avoid a load load race at the end of evacuation. I don't think it 
> > affects performance much. If you have a solution to trigger NPE 
> > correctly on the 2nd instruction and not only the first (e.g. improve 
> > the signal handling), that would be very welcome! 
> > 
> > Cheers, RomanAm 07.09.2016 12:01 nachm. schrieb Aleksey Shipilev 
> > <ashipile at redhat.com>: 
> >> 
> >> Hi, 
> >> 
> >> I am studying the generated code for Shenandoah barriers. These two 
> >>  dereferences seem excessive: 
> >> http://cr.openjdk.java.net/~shade/shenandoah/wb.deref.1/webrev.00/ 
> >> 
> >> 
> >> C1 and interpreter code for both x86_64 and AArch64 do not seem to 
> >> do the additional read barrier before testing 
> >> evacuation_in_progress, doing that only after. Am I missing 
> >> something? 
> >> 
> >> Thanks, -Aleksey