high StringTable scanning overhead during young GCs

[Kim Barrett]

> On Mar 19, 2020, at 12:25 PM, Tony Printezis <tprintezis at twitter.com> wrote:
> 
> 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.

Wow, that's a lot of strings.

As you say, the existing idle mechanism isn't the right approach,
since you aren't actually idle.  But I don't think modifying that
mechanism to ignore young collections is right either.  An application
that really lives in the young-gen and isn't accumulating old objects,
but wants to take advantage of going idle, would get unnecessary
concurrent cycles inflicted 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.

The application could run with -XX:+ExplicitGCInvokesConcurrent and
just call System.gc when it decides that's appropriate.  That requires
the additional CLA that might have unintended effect on other uses of
System.gc though.  I keep circling back to wanting an alternative to
System.gc that will attempt a concurrent collection if that's available.
The application can call that when it thinks it's appropriate.

I'm not fond of the idea of splitting the StringTable into young and
old parts.  That seems like a relatively big hammer for what seems
like a pretty specialized problem.