RFR (S): 8213307: G1 should clean up RMT with ClassUnloadingWithConcurrentMark
shade at redhat.com
Mon Nov 5 14:11:47 UTC 2018
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
I'd keep the original behavior and wait for external timeout. Reason: I am not sure 5 iterations is
enough for every GC :)
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:
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.
1885 GCTraceTime(Debug, gc, phases) t("ResolvedMethodTable", gc_timer);
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",
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the hotspot-gc-dev