RFR(S): 8015237: Parallelize string table scanning during strong root processing
stefan.karlsson at oracle.com
Wed May 29 07:09:29 UTC 2013
On 05/29/2013 12:46 AM, John Cuthbertson wrote:
> Hi Stefan,
> Replies inline....
> 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?
I think you should maintain your own patch for this. No need to litter
the code base with this if its not really needed.
>> 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.
OK. Yes, I agree that it should not be done as a part of this CR.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev