RFR: 8215097: Do not create NonJavaThreads before BarrierSet

Per Liden per.liden at oracle.com
Sun Dec 9 22:31:43 UTC 2018

On 12/09/2018 11:26 PM, Per Liden wrote:
> Hi,
> On 12/09/2018 11:05 PM, David Holmes wrote:
>> Hi Kim,
>> Didn't realize you were going to tackle this so soon. I was just 
>> ironing out the wrinkles in 8214097 before sending it for review later 
>> today. :)
>> On 9/12/2018 6:30 pm, Kim Barrett wrote:
>>> Please review this change to move the construction of some work gang
>>> threads by G1 and CMS to after they've created the barrier set.  This
>>> allows the removal of some bootstrapping code needed to support that
>>> construction order.  There isn't any requirement for the old order,
>>> it seems to just be a historical artifact.
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8215097
>>> Webrev:
>>> http://cr.openjdk.java.net/~kbarrett/8215097/open.00/
>> Moving the GC thread creation out of the heap constructor into the 
>> heap initialize function seems quite reasonable. Does ZGC already 
>> defer the thread creation? Will this impact the merge of Shenandoah?
> ZGC creates the workers in the constructor, and frankly I don't think we 
> want to change that, unless there's some very good reason. I haven't 
> checked Shenandoah.

But I should also add that ZGC registers its barrier set in the 
constructor too, before workers are created, so I don't think Kim's 
patch will cause any problems really. Other collectors typically 
registers their barrier set in initialize(), which I guess is the root 
of the bootstrapping issue.


> cheers,
> Per
>> Everything else seems fine. (I'll be reworking the BarrierSet creation 
>> assertion as part of 8214097.)
>> Thanks,
>> David
>>> Testing:
>>> mach5 tier1-5

More information about the hotspot-dev mailing list