high StringTable scanning overhead during young GCs

[Tony Printezis]

Hi Stefan,

Twitter, of course, has NO idle periods. ;-)

Would there be any objection to extending the G1PeriodicGCInterval
mechanism to ignore young GCs? I’ll be happy to work on it. In our
experience there are a couple of reasons to force cycles at a given
frequency. One (less common for us) is to clear up the StringTable, as I’ve
described already. Another (a lot more common for us) is to force
finalizers / cleaners / and friends to run to clean up native resources
held by dead objects in the old generation. We have had several cases where
services would run out of native memory because cycles would happen very
infrequently and a lot of native memory was held by dead objects in the old
generation. FWIW, this was our original motivation for introducing the
mechanism we have to force CMS cycles at a given frequency.

Tony


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


On March 18, 2020 at 3:55:14 AM, Stefan Johansson (
stefan.johansson at oracle.com) wrote:

Hi Tony,

Yes, if a young GC happens during the interval it will prevent a periodic
concurrent start GC from happening. I see how this might not play well with
your use case, unless your service sometimes have an idle period.

Stefan

> 17 mars 2020 kl. 21:23 skrev Tony Printezis <tprintezis at twitter.com>:
>
> 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