RFR: 8242130: Shenandoah: Simplify arraycopy-barrier dispatching
Aleksey Shipilev
shade at redhat.com
Mon Apr 6 11:09:50 UTC 2020
On 4/6/20 1:01 PM, Roman Kennke wrote:
>>> Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8242130
>>> Webrev:
>>> http://cr.openjdk.java.net/~rkennke/JDK-8242130/webrev.00/
>>
>> *) Is it actually safe to ignore dest_uninitialized path? Would the new arraycopy_marking routine
>> walk over uninitialized memory now?
>
> This is not about safety, it is about optimization: when the destination
> array is uninitialized, we don't need to mark the previous values,
> because they are known to be NULL.
>
> Also, when dest is uninitialized, then we don't include MARKING in the
> gc-state check above. Which means it would never trigger during marking,
> and only during evac, in which case we're looking at the src array only.
>
> Does that make sense?
Ah, I see. Yes, it does make sense.
Looks good then.
Minor nit in shenandoahRuntime.hpp, "narrowOop * dst":
37 static void arraycopy_barrier_narrow_oop_entry(narrowOop* src, narrowOop * dst, size_t length);
--
Thanks,
-Aleksey
More information about the shenandoah-dev
mailing list