RFR: Fix, improve and refactor matrix barrier on AAarch64

[Aleksey Shipilev]

On 09/14/2017 03:20 PM, Roman Kennke wrote:
> This patch fixes an issue in the aarch64 interpreter matrix barrier that caused
> TestGCOldWithShenandoah to fail verification. The reason was that we invoke the
> storeval-(read-)barrier *after* we copied the newval, and then pass the original to the matrix
> barrier, thus connecting the wrong regions.
> 
> The patch does:
> - Move the storeval barrier before copying the newval
> - Add a tmp3 arg to the shenandoah_write_barrier_post() to make it consistent (we've been using 2
> tmp regs passed via function call, and 1 implicit)
> - Implement the fast matrix math as a bonus
> 
> Test: hotspot_gc_shenandoah
> 
> http://cr.openjdk.java.net/~rkennke/fix-matrix-barrier-aarch64/webrev.00/

*) Passing third parameter makes the method consistent with what? shenandoah_write_barrier_post in
x86 uses rscratch1 without having it passed via register. g1_write_barrier_post also does not pass
rscratch1, but uses it.

*) If you are using optimized math, why do you need heap base now?

3925   unsigned long offset;
3926   adrp(tmp3, ExternalAddress(ShenandoahHeap::heap()->base()), offset);
3927   assert(offset == 0, "Heap base address must be page aligned");

Thanks,
-Aleksey