RFR: 8242130: Shenandoah: Simplify arraycopy-barrier dispatching

Roman Kennke rkennke at redhat.com
Mon Apr 6 11:49:29 UTC 2020


Hi Aleksey,

>>>> 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! Pushed with this formatting fixed.

Roman



More information about the shenandoah-dev mailing list