RFR (S): 8209839: [Backout] Backout JDK-8206467 Refactor G1ParallelCleaningTask into shared
Zhengyu Gu
zgu at redhat.com
Wed Aug 22 13:50:35 UTC 2018
Good to me.
-Zhengyu
On 08/22/2018 09:44 AM, Thomas Schatzl wrote:
> Hi all,
>
> can I have reviews for this backout of JDK-8206467 because it
> introduces a deadlock into G1? (Or for that matter, anyone using the
> parallel cleaning task stuff, i.e. Shenandoah)
>
> The newly introduced ResolvedMethodCleaningTask calls
> ResolvedMethodTable::unlink() which tries to grab the
> ResolvedMethodTable_lock in a VM operation that might be held by other
> code at the same time (e.g. compilation).
>
> The change also adds timing in a completely different way than all
> other collectors, which might need reconsideration.
>
> Any change obviously needs more time for rework and testing; further I
> would like to get to some kind of consensus about timing in gc code (at
> least time base and time type), and how to support other collectors,
> which also needs more time to work out. So I consider it best to just
> back out the change for now and try to achieve this step by step
> instead of potentially reworking this change multiple times (and having
> broken code around).
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8209839
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8209839/webrev/
> Testing:
> local compilation
>
> Thanks,
> Thomas
>
More information about the hotspot-gc-dev
mailing list