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