Not triggering concurrent cycle in G1 leaves string table cleanup deferred

For G1 GC, when the (interned) string table gets cleaned is dictated by when mixed GCs happen. Young GCs are insufficient for string table cleaning as a complete assessment of liveness is prerequisite to determining if any given interned string can be disposed of.

It is possible that a program only experiences young collections while creating large numbers of interned strings, occupying extra native memory with unneeded string entries. In extreme cases, this can prematurely exhaust physical memory.

This problem should be very rare in real world applications, but the behavior can be reproduced by a test program (see attachment). Running this program, and observing the GC log as well as NMT, one can see native memory growing and growing without mixed GC happening. It interns lots of different strings and cuts them lose periodically. This is similar to a stateless request handling micro service that uses a (JSON) serialization mechanism which interns strings.

If interned strings and all elements of their table were completely represented as Java objects inside the Java heap, then GC would automatically trigger their cleanup (and all unused memory would be recovered). Short of that solution, there ought to be an additional mechanism that triggers mixed GCs in a timely fashion, e.g., based on string table growth. Alternatively, periodic mixed collections could also prevent unbounded symbol table growth.