high StringTable scanning overhead during young GCs

Tony Printezis tprintezis at twitter.com
Tue Mar 17 20:23:03 UTC 2020


Hi Stefan,

Thanks for mentioning the flag. I’ll take a look. I don’t think we’ll be on
12 or later any time soon, but I can always backport the change if needed.
Quick question: “the periodic request will be skipped if any GC occurred in
the interval”: So, if a young GC happens during the interval, a periodic
concurrent cycle won’t?

Tony


—————
Tony Printezis | @TonyPrintezis | tprintezis at twitter.com


On March 17, 2020 at 5:31:24 AM, Stefan Johansson (
stefan.johansson at oracle.com) wrote:

Hi Tony,

> 16 mars 2020 kl. 22:02 skrev Tony Printezis <tprintezis at twitter.com>:
>
> ...
>
> FWIW, we use mostly CMS in 8 and we addressed this by forcing more
frequent
> CMS cycles (we have a flag that starts a CMS cycle every N secs). This
> helps to keep young GC times mostly in check for our services that suffer
> from this issue.
>
If you want to try a similar workaround for G1. In JDK 12,
G1PeriodicGCInterval was added as part of JEP 346: Promptly Return Unused
Committed Memory from G1. This flag allows you to trigger GCs based on that
interval, and by default the GC triggered start a concurrent cycle. This
feature was mostly designed for idle applications and the periodic request
will be skipped if any GC occurred in the interval, so depending on your
workload disabling adaptive IHOP and setting a lower fixed IHOP might be
better approach.

Thanks,
Stefan

> ...
> —————
> Tony Printezis | @TonyPrintezis | tprintezis at twitter.com



More information about the hotspot-gc-dev mailing list