RFR (S) 8217014: Epsilon should not ignore Metadata GC causes

[Aleksey Shipilev]

RFE:
  https://bugs.openjdk.java.net/browse/JDK-8217014

Fix:
  http://cr.openjdk.java.net/~shade/8217014/webrev.01/

While Epsilon does not do the GC collection cycles, Metadata GC machinery is external to it.
Notably, CollectedHeap::satisfy_failed_metadata_allocation would initiate its own VM operation and
call CollectedHeap::collect_as_vm_thread(GCCause::_metadata_GC_threshold) inside of it. All other
GCs would eventually call MetaspaceGC::compute_new_size during that collection cycle. Epsilon would
not, because it currently ignores the GC requests wholesale.

Since MetaspaceGC::compute_new_size is not called, metaspace would resize a little, but would
re-enter satisfy_failed_metadata_allocation and call for safepoint again rather soon, because the
increment was small. You can see that as the flurry of "Metadata GC Threshold" requests ignored by
Epsilon.

The easy way out is to "handle" the metadata GC requests and call the resize in Epsilon. The change
also hooks up Metadata printing to the GC logging, and adds the test that creates lots of classes to
verify. The example log for new jtreg test:

[0.003s][info][gc] Non-resizeable heap; start/max: 128M
[0.003s][info][gc] Using TLAB allocation; max: 4096K
[0.003s][info][gc] Elastic TLABs enabled; elasticity: 1.10x
[0.003s][info][gc] Elastic TLABs decay enabled; decay time: 1000ms
[0.003s][info][gc] Using Epsilon
[0.279s][info][gc] Heap: 128M reserved, 128M (100.00%) committed, 6M (5.24%) used
[0.945s][info][gc          ] Heap: 128M reserved, 128M (100.00%) committed, 39M (30.64%) used
[0.945s][info][gc,metaspace] Metaspace: 36M reserved, 15M (44.10%) committed, 14M (40.62%) used
[1.225s][info][gc          ] GC request for "Metadata GC Threshold" is handled
[1.225s][info][gc,metaspace] Metaspace: 38M reserved, 20M (54.73%) committed, 19M (51.48%) used
[1.326s][info][gc          ] Heap: 128M reserved, 128M (100.00%) committed, 64M (50.17%) used
[1.326s][info][gc,metaspace] Metaspace: 40M reserved, 25M (64.18%) committed, 24M (60.64%) used
<end>

For more realistic example, before the change the startup of springboot-petclinic with Epsilon does
110 (!) "Metadata GC Threshold" requests in first 5 seconds, each of those in its own safepoint.
After this change we only do 3 requests, and thus significantly less safepoints.

Testing: hotspot tier1, gc/epsilon, jdk-submit, new test

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/20190116/352375e6/signature.asc>