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

Aleksey Shipilev shade at redhat.com
Fri Sep 21 10:47:08 UTC 2018


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



More information about the shenandoah-dev mailing list