Why to do StringTable collection on each ParallelScavenge?

Cheremin Ruslan cheremin at gmail.com
Fri Sep 9 14:06:38 UTC 2016

During profiling GC in my app with FlightRecorder I find out StringTable collection takes noticeable amount of time.  
E.g. ParallelScavenge takes ~3ms in total, with Scavenge phase takes ~2ms, and StringTable collection takes ~800us – i. e. it is 1/3 to 1/4 of total GC time.  
By looking HotSpot code I see StringTable collection is unconditional – i.e. there is no flags to prevent it.   

As far, as I understand, StringTable is for intern-ed strings, and in well-behaving app it should be limited count of intern-ed string.  
I.e. StringTable should (most-probably, in well-behaving apps) reach some steady-state with more-or-less stable content.  
I this is correct, then cleaning StringTable looks like a rare task, suitable for Major/Full GC, but not Minor one. So I’m curious: why it is so important to collect StringTable on each Minor GC? (And, may be, is it still possible to somehow disable it?)
(I’m, using HotSpot for linux-amd64 1.8.0_102-b14 64-Bit Server VM)


More information about the hotspot-gc-dev mailing list