high StringTable scanning overhead during young GCs

[Tony Printezis]

Hi all,

We have seen the following issue a few times in our data centers: A service
is interning strings at a steady rate. The interned strings live long
enough to be promoted to the old generation. They are reclaimed during the
following Full GC / concurrent cycle. However, until that happens, young GC
times are monotonically increasing as young GCs have to scan the entire
StringTable, which keeps growing in size.

I can reproduce this with the latest 15, with both G1 and ParallelGC.

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.

However, this overhead could be avoided if the StringTable was split into
two parts, one for entries that could potentially point into the young gen,
the other for entries that definitely do not point into the young gen. Each
young GC will only have to scan the former (similar to what was done for
nmethods).

Has anyone looked into this?

Thanks,

Tony



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