high StringTable scanning overhead during young GCs

[Kim Barrett]

> On Mar 16, 2020, at 5:02 PM, Tony Printezis <tprintezis at twitter.com> wrote:
> 
> 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?

All young collections treat the StringTable as weak.  (I think only
Parallel used to, but that was changed a while ago.)  Young collection
processing of a weak entry is relatively cheap when the referent is
old (determine that it's not in the collection set, so do nothing).

(since JDK 12?) G1 parallelizes StringTable processing (in conjunction
with several other kinds of off-heap weak references, such as JNI weak
references).  So one would think it would require a pretty large
number of old StringTable entries to have a significant effect.

ParallelGC currently processes the StringTable single threaded; there's
an RFE to parallelize it (JDK-8210100).

Can you provide some numbers / log data? If there is a performance
problem there, maybe there's just a bug somewhere that needs to be
fixed. I think splitting the StringTable that way isn't entirely
trivial, and would need pretty strong justification.