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