RFR(S): 8015237: Parallelize string table scanning during strong root processing
stefan.karlsson at oracle.com
Mon May 27 19:16:32 UTC 2013
On 2013-05-25 00:19, John Cuthbertson wrote:
> Hi Everyone,
> Can I have a couple of reviewers look over these changes - the webrev
> is: http://cr.openjdk.java.net/~johnc/8015237/webrev.0/
Not a complete review, yet. But I have a couple of comments from
browsing through the patch.
There's a lot of places where you have add an extra worker_id parameter.
It's only used for one out-commented print statement and a very
toothless assert. If you remove that, the patch will shrink from ten
files changed to three files changed and we'll keep the
process_strong_roots functions from getting more parameters.
Have you also consider to parallelize the StringTable::unlink function?
> 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
> summarized here:
> 0-threads (ms)
> 1-thread-chunked (ms)
> Min 0.200
> Max 6.900
> Avg 0.658
> These were from 1 hour long runs of Kitchensink with around ~2800 GCs
> in each run.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev