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

Roman Kennke rkennke at redhat.com
Tue Jun 19 08:32:51 UTC 2018


Am 19.06.2018 um 10:20 schrieb Aleksey Shipilev:
> On 06/19/2018 10:05 AM, Roman Kennke wrote:
>> http://cr.openjdk.java.net/~rkennke/traversal-arraycopy/webrev.01/
> 
> *) In the SBS methods where you add the push_arraycopy block, there is already
> _heap->is_concurrent_traversal_in_progress() branch that you can reuse. It also has oop(mr.start())
> handy already. After this move, non-traversal GC would not be penalized.

Right! I did this before you re-arranged those checks..

> *) I'd add new lines around this block, because it is semantically distinct from everything else:
> 
>  611     }
>          // here
>  612     if (_arraycopy_task_queue.length() > 0) {
>  613       process_arraycopy_task(cl);
>  614     }
>          // and here
>  615     uint work = 0;

Ok, done.

> *) This check could be turned into pre-condition before pushing on the arraycopy queue?
> 
> 1172 bool ShenandoahTraversalGC::process_arraycopy_task(T* cl) {
> 1174   if (task.start() == NULL) {
> 1175     return false;
> 1176   >
> I assume you have run performance tests with it to justify its usefulness? :)

No. We must actually never get there. This used to serve as a
no-more-work marker. But then I added queue->length() checks and should
no longer be needed. I removed the related code and turned the check
into an assert.

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

Ok now?

Roman



More information about the shenandoah-dev mailing list