Expand shenandoah write barrier as C2 IR

Roman Kennke rkennke at redhat.com
Tue Oct 25 19:30:24 UTC 2016


Hi Roland,

This looks like an awesome improvement to me!

I'm worried about all those not-obviously Shenandoah related changes in
there. Do we have a chance to eventually get them accepted upstream? Or
can we somehow contain them?

I also see you sneaked in a loadload barrier, presumably for the acmp
barrier, but I don't see it inserted there. ?

Roman

Am Dienstag, den 25.10.2016, 18:16 +0200 schrieb Roland Westrelin:
> http://cr.openjdk.java.net/~roland/shenandoah/wb2ir/webrev.00/
> 
> This expands the write barrier to c2 IR after most optimizations are
> over. It also takes care of finding a dominating null check and
> reshapes
> the graph to enable implicit null checks. This method:
> 
>     static void m9(A a) {
>         a.f = 0x42;
>     }
> 
> is compiled to (on x86):
> 
>   0x00007fa4bcb4bb4c: movzbl 0x640(%r15),%r11d
>   0x00007fa4bcb4bb54: test   %r11d,%r11d
>   0x00007fa4bcb4bb57: jne    0x00007fa4bcb4bb70
>  ;; B2: #	B6 B3 <- B1  Freq: 0.999
> 
>   0x00007fa4bcb4bb59: mov    -0x8(%rsi),%rax    ; implicit exception:
> dispatches to 0x00007fa4bcb4bb83
>  ;; B3: #	N1 <- B2 B5  Freq: 0.999999
> 
>   0x00007fa4bcb4bb5d: movl   $0x42,0x10(%rax)   ;*putfield f
> {reexecute=0 rethrow=0 return_oop=0}
>                                                 ; -
> TestShenandoahBarrier::m9 at 3 (line 66)
> 
>   0x00007fa4bcb4bb64: add    $0x10,%rsp
>   0x00007fa4bcb4bb68: pop    %rbp
>   0x00007fa4bcb4bb69: test   %eax,0x14487491(%rip)        #
> 0x00007fa4d0fd3000
>                                                 ;   {poll_return}
>   0x00007fa4bcb4bb6f: retq   
>  ;; B4: #	B6 B5 <- B1  Freq: 0.000999987
> 
>   0x00007fa4bcb4bb70: mov    -0x8(%rsi),%rdi    ; implicit exception:
> dispatches to 0x00007fa4bcb4bb83
>  ;; B5: #	B3 <- B4  Freq: 0.000999986
> 
>   0x00007fa4bcb4bb74: movabs $0x7fa4bc94a8e4,%r10
>   0x00007fa4bcb4bb7e: callq  *%r10
>   0x00007fa4bcb4bb81: jmp    0x00007fa4bcb4bb5d
> 
> and on aarch64:
> 
>   0x000003ff84b49cd4: ldrb      w11, [xthread,#1600]
>   0x000003ff84b49cd8: dmb       ishld
>   0x000003ff84b49cdc: cbnz      w11, 0x000003ff84b49d00
>  ;; B2: #       B6 B3 <- B1  Freq: 0.999
> 
>   0x000003ff84b49ce0: ldr       x0, [x1,#-8]    ; implicit exception:
> dispatches to 0x000003ff84b49d0c
>  ;; B3: #       N1 <- B2 B5  Freq: 0.999999
> 
>  ;; 0x42
>   0x000003ff84b49ce4: mov       w10, #0x42                      //
> #66
>   0x000003ff84b49ce8: str       w10, [x0,#16]   ;*synchronization
> entry
>                                                 ; -
> TestShenandoahBarrier::m9 at -1 (line 66)
> 
>   0x000003ff84b49cec: ldp       xfp, xlr, [sp,#16]
>   0x000003ff84b49cf0: add       sp, sp, #0x20
>   0x000003ff84b49cf4: adrp      xscratch1, 0x000003ff976d0000
>                                                 ;   {poll_return}
>   0x000003ff84b49cf8: ldr       wzr, [xscratch1]  ;   {poll_return}
>   0x000003ff84b49cfc: ret
>  ;; B4: #       B6 B5 <- B1  Freq: 0.000999987
> 
>   0x000003ff84b49d00: ldr       x0, [x1,#-8]    ; implicit exception:
> dispatches to 0x000003ff84b49d0c
>  ;; B5: #       B3 <- B4  Freq: 0.000999986
> 
>   0x000003ff84b49d04: bl        Stub::shenandoah_wb+4
> 0x000003ff849bf994
>                                                 ;   {runtime_call
> StubRoutines (3)}
>   0x000003ff84b49d08: b 0x000003ff84b49ce4
> 
> This is off by default for now as I'm seeing some hangs on aarch64.
> 
> Roland.


More information about the shenandoah-dev mailing list