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

[Stefan Karlsson]

On 05/27/2013 09:16 PM, Stefan Karlsson wrote:
> 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?

I've looked through the patch and I think it looks good.

However, I think that you should remove the added worker_id parameters 
and I sympathize with Thomas' concern about the code duplication.

thanks,
StefanK
>
> 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/20130528/2c6f1b30/attachment.htm>