[aarch64-port-dev ] RFR(S): 8216989 - CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not check for zero length on AARCH64

[Dmitrij Pochepko]

Hi Andrew,

Thank you for review.
pushed to jdk/jdk (had to resolve 1 hunk, because of 
http://hg.openjdk.java.net/jdk/jdk/rev/f4f0dce5d0bb).

And I'm going to propose this patch for backporting into 11u and 12u 
(Final jdk/jdk patch doesn't apply cleanly for both. Separate webrevs 
and testing will be provided later).

Thanks,
Dmitrij

On 25/03/2019 1:01 PM, Andrew Dinn wrote:
> Hi Dmitrij,
>
> On 20/03/2019 17:29, Dmitrij Pochepko wrote:
>> Please take a look at
>> http://cr.openjdk.java.net/~dpochepk/8216989/webrev.02/
>> I changed patch according to x86 fix and current code layout:
>>
>> - renamed methods parameters from "end" to "count" to avoid confusing
>> names and match x86
>> - updated G1BarrierSetAssembler::gen_write_ref_array_post_barrier
>> implementation: removed code with calculation of "count" value and using
>> "count" directly instead
>> - updated ShenandoahBarrierSetAssembler::arraycopy_epilogue in same way
>> as G1 code
>> - updated CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier
>> with zero length branch and calculation of inclusive end pointer to
>> match original logic
>> - updated arraycopy_epilogue usage by removing unnecessary end pointer
>> calculation and providing array length (count) instead
>>
>> I also run jtreg hotspot/compiler, hotspot/gc, hotspot/runtime and jck
>> with G1GC, ParallelGC and ShenandoahGC
>> No regressions found.
> Yes, with that change AArch64 matches the x86 code and the changes are
> consistent with the JDK8 change set that Andrew identified as the reason
> why AArch64 and x86 diverged. So, it's ok to push.
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander