RFR (S): 8213307: G1 should clean up RMT with ClassUnloadingWithConcurrentMark

[Aleksey Shipilev]

On 11/05/2018 01:53 PM, Thomas Schatzl wrote:
> I also made the test to not go into an infinite loop if no RMT
> unloading occurs as this would make it wait on external timeout which
> seems ugly. If somebody disagrees with that change I can easily revert
> it.

I'd keep the original behavior and wait for external timeout. Reason: I am not sure 5 iterations is
enough for every GC :)

> CR:
> https://bugs.openjdk.java.net/browse/JDK-8213307
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8213307/webrev/

Looks okay to me.

*) While we are at it, both these GCTraceTime hooks seem to be misplaced. They should be moved where
the actual cleanup is taking place:

1877   {
1878     GCTraceTime(Debug, gc, phases) t("ProtectionDomainCacheTable", gc_timer);
1879     // Oops referenced by the protection domain cache table may get unreachable independently
1880     // of the class loader (eg. cached protection domain oops). So we need to
1881     // explicitly unlink them here.
1882     _pd_cache_table->trigger_cleanup();
1883   }
1884
1885   GCTraceTime(Debug, gc, phases) t("ResolvedMethodTable", gc_timer);
1886   ResolvedMethodTable::trigger_cleanup();
1887

That should probably go to another RFR. Still, it seems cleaner to have the scope around
RMT::trigger_cleanup to make sure the GCTraceTime relates to that operation only, in case some new
code appears after it.

*) I'd consider conditionalizing ClassUnloadingWithConcurrentMark too in the test -- we want to
cover the Full GC case too, no?

 82         doConcurrent ? "-XX:+ExplicitGCInvokesConcurrent" : "-XX:-ExplicitGCInvokesConcurrent",
 83                        "-XX:+ClassUnloadingWithConcurrentMark",

Thanks,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20181105/3dd17010/signature.asc>