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