RFR: 8215097: Do not create NonJavaThreads before BarrierSet

[Per Liden]

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

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