RFR: Improve AArch64 matrix barrier (was: Re: RFR: Fix, improve and refactor matrix barrier on AAarch64)

Roman Kennke rkennke at redhat.com
Thu Sep 28 10:34:42 UTC 2017


Am 25.09.2017 um 12:01 schrieb Andrew Haley:
> On 14/09/17 16:20, Aleksey Shipilev wrote:
>> On 09/14/2017 05:19 PM, Roman Kennke wrote:
>>>>> http://cr.openjdk.java.net/~rkennke/fix-matrix-barrier-aarch64/webrev.01/
>>>> Good, except for rscratch1 change.
>>> Ok, I made it a compromise: kept the method signature the same (i.e. 2 tmp args), and declare tmp3
>>> at the beginning of the code block to be rscratch1.
>>>
>>> http://cr.openjdk.java.net/~rkennke/fix-matrix-barrier-aarch64/webrev.02/
> This is confusing code.  Giving rscratch1 a name like "tmp3" doesn't
> help anyone, and it adds risk because many macros implicitly clobber
> rscratch1.  Something like this (untested) is clearer:
>
>    // Compute matrix index
>
>    mov(rscratch1, matrix->stride_jint());
>    // Address is _matrix[to * stride + from]
>    madd(tmp, tmp, rscratch1, tmp2);
>    mov(rscratch1, matrix->magic_offset());
>    Address loc(tmp, rscratch1);
>
>    ldrb(tmp2, loc);
>    cbnzw(tmp2, done);
>    mov(tmp2, 1);
>    strb(tmp2, loc);
>    bind(done);

Yes, this is indeed better. Tested on aarch64 using 
hotspot_gc_shenandoah jtreg tests:
http://cr.openjdk.java.net/~rkennke/fix-aarch64-matrix-barrier/webrev.00/ 
<http://cr.openjdk.java.net/%7Erkennke/fix-aarch64-matrix-barrier/webrev.00/>

Ok to push?

Roman



More information about the shenandoah-dev mailing list