high StringTable scanning overhead during young GCs

[Tony Printezis]

Hi Kim,

Please see inline.


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


On March 20, 2020 at 12:06:36 AM, Kim Barrett (kim.barrett at oracle.com)
wrote:

> 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.


Yes.



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.


I think I was a bit unclear. I was suggesting to add a new flag to be able
to do either. Either a boolean flag to ignore young GCs or have two
different interval flags (G1PeriodicGCInterval and G1PeriodConcGCInterval).



> 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.


Of course. We can also provide our own API to start a concurrent cycle
without setting +ExplicitGCInvokesConcurrent. But it’s always much easier
to add a flag that does what we want instead of having to make code changes.


 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.


So, playing Devil’s advocate, why was it done for nmethods?


Tony