RFR(S): 8015237: Parallelize string table scanning during strong root processing

[Stefan Karlsson]

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?

thanks,
StefanK

> Summary:
> 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.
>
> Testing
> Kitchensink; jprt; GC test suite. With all collectors.
>
> Overhead:
> 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
> 	0.300
> Max 	6.900
> 	8.800
> Avg 	0.658
> 	0.794
>
>
> These were from 1 hour long runs of Kitchensink with around ~2800 GCs 
> in each run.
>
> Thanks,
>
> JohnC

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130527/3bd489a5/attachment.htm>