RFR(S): 8015237: Parallelize string table scanning during strong root processing
john.cuthbertson at oracle.com
Fri May 24 22:19:51 UTC 2013
Can I have a couple of reviewers look over these changes - the webrev
On some workloads we are seeing that the scan of the intern string table
(among others) can sometimes take quite a while. This showed up on some
FMW workloads with G1 where the scan of the string table dominated the
pause time for some pauses. G1 was particularly affected since it
doesn't do class unloading (and hence pruning of the string table)
except at full GCs. The solution was to change the string table from
being considered a single root task and treat similarly to the Java
thread stacks: each GC worker claims a given number of buckets and scans
the entries in those buckets.
Kitchensink; jprt; GC test suite. With all collectors.
Not real performance numbers but I did some measurement of the
synchronization overhead of using 1 GC worker thread. They are
These were from 1 hour long runs of Kitchensink with around ~2800 GCs in
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev