RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results

[Hohensee, Paul]

I’d appreciate a review please.

Bug: https://bugs.openjdk.java.net/browse/JDK-8195115
Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.00/

The bug is that from the JMX point of view, G1’s incremental collector (misnamed as the “G1 Young Generation” collector) only affects G1’s survivor and eden spaces. In fact, mixed collections run by this collector also affect the G1 old generation.

This proposed fix is to record, for each of a JMX garbage collector's memory pools, whether that memory pool is affected by all collections using that collector. And, for each collection, record whether or not all the collector's memory pools are affected. After each collection, for each memory pool, if either all the collector's memory pools were affected or the memory pool is affected for all collections, record CollectionUsage for that pool.

For collectors other than G1 Young Generation, all pools are recorded as affected by all collections and every collection is recorded as affecting all the collector’s memory pools. For the G1 Young Generation collector, the G1 Old Gen pool is recorded as not being affected by all collections, and non-mixed collections are recorded as not affecting all memory pools. The result is that for non-mixed collections, CollectionUsage is recorded after a collection only the G1 Eden Space and G1 Survivor Space pools, while for mixed collections CollectionUsage is recorded for G1 Old Gen as well.

Other than the effect of the fix on G1 Old Gen MemoryPool. CollectionUsage, the only external behavior change is that GarbageCollectorMXBean.getMemoryPoolNames will now return 3 pool names rather than 2.

With this fix, a collector’s memory pools can be divided into two disjoint subsets, one that participates in all collections and one that doesn’t. This is a bit more general than the minimum necessary to fix G1, but not by much. Because I expect it to apply to other incremental region-based collectors, I went with the more general solution. I minimized the amount of code I had to touch by using default parameters for GCMemoryManager::add_pool and the TraceMemoryManagerStats constructors.

Tested by running the new jtreg test included in the webrev. I tried to use the submit repo, but it was out of order earlier today, so I’d be much obliged if someone could run it through mach5 and sponsor an eventual push. I successfully ran a JDK8 version of the patch through all the JDK8 jtreg tests as well as the JDK8 TCK.

Thanks,

Paul


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180119/256ae370/attachment.html>