[aarch64-port-dev ] RFR(S): 8216989 - CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not check for zero length on AARCH64
dmitrij.pochepko at bell-sw.com
Wed Mar 20 17:29:47 UTC 2019
On 19/03/2019 2:16 PM, Andrew Dinn wrote:
> On 19/03/2019 10:52, Andrew Haley wrote:
>> On 3/19/19 10:04 AM, Andrew Dinn wrote:
>>> On AArch64 for some unexplained reason it is the stub code which
>>> modifies cnt, performing the decrement and address add.
>> That's how x86 did it back then. x86 got fixed by
>> We should look at that patch *extremely* *carefully*, and make sure we've
>> got all the fixes. The AArch64 version is based on that code, so it will
>> probably have inherited its bugs.
> Ok, noted.
> Dmitrij, please prepare a revised patch to re-align AArch64 with x86_64
> as previously recommended and then check it is consistent with the above
> commit. I'll do the same at re-review to ensure that we have two sets of
> eyes on the problem.
Please take a look at
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev