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

[Stefan Karlsson]

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.

thanks,
StefanK

>
> JohnC
>

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