high StringTable scanning overhead during young GCs

[Ioi Lam]

Where do these interned strings come from? Are they from class files, or 
are they created dynamically due to program execution.

If the set of strings are mostly static, they can be stored in the CDS 
archived. These strings are not scanned during GC.

Thanks
- Ioi

On 3/20/20 8:07 AM, Tony Printezis wrote:
> 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