RFR: Code root iterators should not be instantiated in worker threads

[Roman Kennke]

Am 21.09.2018 um 12:47 schrieb Aleksey Shipilev:
> http://cr.openjdk.java.net/~shade/shenandoah/traversal-coderoots-iter/webrev.01/
> 
> Following up on the recent test failure that looks like a garbled code root. This is the race
> between two GC threads: each of those threads have their own code iterator, and so they visit the
> same nmethods. MarkingCodeBlobClosure prevents from the massive breakage in this case, but the
> assertion code in code roots iteration would still occasionally see the transient garbled oop from
> another thread updates, before checking with MarkingCodeBlobClosure about this. This is also a
> performance problem, because each GC worker would walk all recorded nmethods, instead of
> coordinating the striding with shared iterator.
> 
> This only affects Traversal. The simplest solution is to forbid worker threads getting the iterators
> for themselves. The cleaner solution would be to call Root{Processor,Evacuator} on this path, but it
> would run into problems, e.g. thread parity checks. The semi-clean solution would be to introduce
> another method into RootProcessor that would only walk CSet code roots.
> 
> Testing: tier3_gc_shenandoah (running)
> 
> Thanks,
> -Aleksey
> 

That's good. Push it.

We should also check our uses of MarkingCodeBlobClosure: they are not
actually needed because claiming is done by our iterators. And as this
bug illustrate, they only help to hide actual bugs ;-) We should replace
them all with ordinary CodeBlobToOopClosure instead.

Thanks,
Roman