RFR(L): 8196889: Revamp G1 JMX MemoryPoolMXBean, GarbageCollectorMXBean, and jstat counter definitions

[Hohensee, Paul]

Please review.

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

This webrev is marked ‘L’ because it’s a behavioral change (CSR in draft state, may I have a review of that too please?) and because the test change fanout is large. The actual code changes are ‘M’.

Passes the submit repo, Hotspot tier1, the JFR gc event tests and any other test set with ‘gc’ or ‘serviceability’ in the test directory name. I found it difficult to verify the accuracy of the reported values other than manually, since they can vary from run to run of the same program. I’d appreciate suggestions for how to go about writing accuracy tests.

I set out originally to revamp only the MXBeans, but decided it would be incomplete if I didn’t include the jstat counters and the output of the GC.heap_info jcmd option. I can separate the latter two into their own RFEs, but I find it easier understand it all in a single webrev and hope the reviewers will too.

The basic approach is to add the new memory pools and collectors, the new jstat counters, and an archive region counter that stands in for an actual archive region set. HeapRegionSets are disjoint, so initially I tried to create a first-class archive region set (on the same level as the humongous region set), but that idea foundered on the fact that there’s too much code I don’t fully understand that depends on archive regions being in the existing old region set. Externally (i.e., in the MXBeans and the jstat counters), however, the old region set doesn’t include archive regions (unless running in legacy mode).

I used CMS’s TraceCMSMemoryManagerStats class as the model for TraceConcMemoryManagerStats, which latter collects statistics on concurrent cycles. There are two STW pauses in each concurrent cycle: they are recorded separately and count as two sun.gc.collector.2 events.

The humongous and archive space committed and used values are always identical, hence they are always 100% used.

The revised output of jcmd GC.heap_info is in G1CollectedHeap::print_on().
I fixed a typo in src/hotspot/share/gc/g1/g1Policy.hpp by changing the result type of young_list_target_length() from size_t to uint, which latter is the type of the _young_list_target_length member.
I updated the copyright date in src/hotspot/share/services/memoryService.hpp to 2018, as I neglected to do so in a previous push.
Thanks,
Paul



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180720/31bc4f30/attachment-0001.html>