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

John Cuthbertson john.cuthbertson at oracle.com
Tue May 28 22:46:05 UTC 2013


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?

>
> 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.

JohnC

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20130528/a9e204f6/attachment.htm>


More information about the hotspot-gc-dev mailing list