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

[Thomas Stüfe]

Hi Alexey,

looks good.

In your test you could set the initial metaspace size to a small size too
for added effect, this triggers a lot of resizing early on (eg
-XX:MetaspaceSize=1m).

nit: EpsilonHeap::print_metaspace_info(): I assume this cannot be called
before metaspace is set up. Still, would prefer checking for reserved=0
before printing the percentages.

Cheers, Thomas




On Wed, Jan 16, 2019 at 6:23 PM Aleksey Shipilev <shade at redhat.com> wrote:
>
> 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 --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20190116/422f1f25/attachment.htm>