RFR: Fix, improve and refactor matrix barrier on AAarch64

[Roman Kennke]

Am 14.09.2017 um 15:52 schrieb 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.
Most with itself. It seemed wrong to me to declare two temp regs as 
args, then use 3, and use 1 implicitely. Also, it made 
experimenting/changing temp reg while debugging easier. Do you want me 
to change it back?
> *) 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");

Good catch!

http://cr.openjdk.java.net/~rkennke/fix-matrix-barrier-aarch64/webrev.01/ 
<http://cr.openjdk.java.net/%7Erkennke/fix-matrix-barrier-aarch64/webrev.01/>

Better?
Roman