<html><head></head><body>Aha, OK then. This is what I needed to know.<br><br>Thanks,<br>Roman<br><br><br><div class="gmail_quote">Am 16. Juni 2019 16:21:10 MESZ schrieb Zhengyu Gu <zgu@redhat.com>:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail"><br><br>On 6/16/19 7:27 AM, Roman Kennke wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Hi Zhengyu,<br><br>So as far as I can see, we are looking at 2 potential issues:<br><br>- Non-GC safepoint work might use our GC workers. This would only<br>possibly be heap-iteration, and as far as I remember, heap-iteration is<br>single-threaded and uses the VMThread. Besides: if this would happen,<br>we'd already have the problem. I don't think this is the case.<br>(Safepoint cleanup has this problem, and we use a separate thread pool<br>for precisely this reason.)<br></blockquote><br>Right. It is single-threaded.<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><br>- Non-GC safepoint work needs to look at GC roots, and concurrent<br>processing of GC roots might conflict with that.<br><br>As far as I see it, this problem could also be solved by employing the<br>correct barriers. I believe this only affects heap-iteration. So when<br>heap-iteration scans the GC roots (during conc-evac), it needs to do the<br>LRB to avoid exposing from-space-objects in the iteration. Later on,<br>when we also want to do concurrent cleanup, it also needs to filter<br>unreachable objects by not seeding the iteration with objects that are<br>unreachable (as per the marking bitmap, not the aux bitmap!).<br><br></blockquote>Our current solution is to use the same roots for heap iteration, as <br>current GC cycle, so both see the same live object graph.<br><br>At this phase, the problems I saw, I think, can be solved with <br>additional cares to avoid suspending workers, e.g. not clear claimed <br>flag for CLDG and using _claim_none to for heap iteration, etc. but I <br>don't think it worth the efforts.<br><br>This change is inavoidable for concurrent class unloading and concurrent <br>code root processing:<br><br>- SystemDictionary::do_unloading(), by design, can not run through <br>safepoints (JDK-8222223),<br><br>- Some CLDG related VM operations, such as ClassLoaderStatsOperation and<br>ClassLoaderHierarchyOperation are no longer safe, if class unloading run <br>through them.<br><br>- I suspect some IC related also no longer safe.<br><br>-Zhengyu<br><br><br><br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">I might be missing something there?<br><br>The reason why I'm looking at avoiding stopping GC threads at safepoints<br>is that it may introduce additional latencies when bringing Java threads<br>to (non-GC) safepoints like biased locking or deopt, by having them wait<br>for GC work (especially when we have non-interruptible not-quite-short<br>GC work like GC roots processing).<br><br>Roman<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">On 6/15/19 9:26 PM, Zhengyu Gu wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">On 6/15/19 3:35 PM, Roman Kennke wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;">Can you give a little bit of explanation why workers need to be<br>suspended at safepoints for concurrent root processing?<br></blockquote><br> Concurrent processing uses workers and safepoint parallel task also<br> utilizes workers, and shenandoah shares workers, so they can not overlap.<br></blockquote><br> Should be more articulate. I don't mean GC safepoint parallel tasks,<br> which can not overlap. But the tasks, such as, heap iteration that might<br> utilize workers.<br><br> Also, heap iteration walks CLDG at a safepoint, that may interfere CLDG<br> walking during concurrent CLDG evacuation.<br><br> -Zhengyu<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><br><br> -Zhengyu<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"><br> Other than that, the patch looks good.<br><br> Roman<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #e9b96e; padding-left: 1ex;"> Please review this patch that makes suspendible workers required,<br> instead of optional, and obsoletes the corresponding flag.<br><br> Suspendible workers are required for concurrent root processing.<br><br> Bug: <a href="https://bugs.openjdk.java.net/browse/JDK-8225813">https://bugs.openjdk.java.net/browse/JDK-8225813</a><br> Webrev:<br> <a href="http://cr.openjdk.java.net/~zgu/JDK-8225813/webrev.00/index.html">http://cr.openjdk.java.net/~zgu/JDK-8225813/webrev.00/index.html</a><br><br> Test:<br> hotspot_gc_shenandoah (fastdebug and release)<br><br> Thanks,<br><br> -Zhengyu<br></blockquote><br></blockquote></blockquote></blockquote><br></blockquote></pre></blockquote></div><br>-- <br>Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.</body></html>