high StringTable scanning overhead during young GCs

[Tony Printezis]

On March 20, 2020 at 10:54:12 AM, Tony Printezis (tprintezis at twitter.com)
wrote:


 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?


Actually, one more thing: The fact that we are causing concurrent cycles
every 6 hours is definitely diminishing the problem. However, note that
Young GC times between cycles go up by between 3x and 6x depending on load.
They drop after each cycle but they keep going up until the next cycle. If
we could split the StringTable and avoid scanning the old part, young GCs
would now stay flat. The problem would be that, if we did cycles every 3 to
4 days, scanning the StringTable during the remark pause would be super
slow, as it will have grown very large (could be seconds just to scan the
StringTable). So, a combination of a split StringTable + frequent cycles
will probably yield the best of both worlds. Anyway, I thought I’d point
that out.


Tony



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