RFR: Check heap stability in C1 WBs

[Roman Kennke]

I think the weird 'nesting' of checks was because of the load-load race of concurrently turning off evac. This is not the case anymore.

I wonder if we should keep the heapstable state in a separate register and avoid reloading it all the time? Probably less so with Roland's happy-path work though...

Patch is good. Thanks!
Roman

Am 21. Mai 2018 14:23:44 MESZ schrieb Aleksey Shipilev <shade at redhat.com>:
>http://cr.openjdk.java.net/~shade/shenandoah/c1-wb-stable/webrev.01/
>
>C2 now has the stable checks before RB-on-WB-fastpath. C1 should do the
>same, see the patch. This
>improves Shenandoah+C1 performance around 0..3% across SPECjvm
>benchmarks. The only suspicious thing
>for me is why the original code shape did the RB in-between the
>evac-check. I suspected implicit
>null checks, but C1 seems to null-check explicitly before calling into
>MASM::shenandoah_write_barrier.
>
>Testing: {x86_64, aarch64} builds, x86_64 hotspot_gc_shenandoah,
>{x86_64, aarch64} benchmarks
>
>Thanks,
>-Aleksey

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.