RFR: 8215097: Do not create NonJavaThreads before BarrierSet

Roman Kennke rkennke at redhat.com
Sun Dec 9 22:37:10 UTC 2018

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

Shenandoah also creates workers in constructors. May I request to hold
this off a little bit to avoid making a mess out of the very soon
upstream push? I'm open to moving this into initialize() but I cannot
tell real quick if it has or hasn't any funny side-effects.


More information about the hotspot-dev mailing list