RFR (S): 8209839: [Backout] Backout JDK-8206467 Refactor G1ParallelCleaningTask into shared

[Thomas Schatzl]

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