RFR: Implement arraycopy post-processing in GC threads for Traversal GC

[Roman Kennke]

Am 19.06.2018 um 10:39 schrieb Aleksey Shipilev:
> On 06/19/2018 10:32 AM, Roman Kennke wrote:
>> Incremental:
>> http://cr.openjdk.java.net/~rkennke/traversal-arraycopy/webrev.02.diff/
>> Full:
>> http://cr.openjdk.java.net/~rkennke/traversal-arraycopy/webrev.02/
> 
> *) Stray white-space:
> 
>  219
> 
> 
> *) The check shapes are different, let's stick with fall-through? It would help my SBS lag tracing
> patch too.
> 
>  121     if (count > ShenandoahEnqueueArrayCopyThreshold) {
>  122       _heap->traversal_gc()->push_arraycopy(start, count);
>  123       return; <--- early return
>  124     }
> 
> 
>  230     if ((size_t) obj->size() > ShenandoahEnqueueArrayCopyThreshold) {
>  231       _heap->traversal_gc()->push_arraycopy(mr.start(), 0);
>  232     } else {  <--- fall-through
> 
> Otherwise looks good, no need for another webrev.
> 

Ok, I changed that.

It turns out that we do have to do the NULL-check. Checking for length
is racy, doing it non-race means we'd have to take the lock every time
we go there. It seems better to make a racy check, and then return NULL
if queue is indeed empty, and handle it specially.

Incremental:
http://cr.openjdk.java.net/~rkennke/traversal-arraycopy/webrev.03.diff/
Full:
http://cr.openjdk.java.net/~rkennke/traversal-arraycopy/webrev.03/

Passes tier3_gc_shenandoah

Ok?