RFR(S): 8015237: Parallelize string table scanning during strong root processing
john.cuthbertson at oracle.com
Tue May 28 22:46:05 UTC 2013
On 5/27/2013 12: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.
I added the extra parameter because I've added it 3 times to different
changes for PSR runs and my own tracing to verify the distribution of
work among the threads. If I have to add it again for another change -
it stays then OK?
> Have you also consider to parallelize the StringTable::unlink function?
I didn't. I was focused on the G1 data generated by my instrumented runs
from PSR - which only indicated that the scanning was an issue.
Parallelization of the unlink could be achieved in a similar way but we
would need to wrap the unlink calls in suitable work gang tasks for the
frame work collectors or ParallelScavenge/ParallelCompact GC tasks for
parallel GC. I think that should be a separate CR.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev