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

[John Cuthbertson]

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/

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/20130524/3380d8c4/attachment.htm>