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