RFR: 8215097: Do not create NonJavaThreads before BarrierSet
kim.barrett at oracle.com
Mon Dec 10 21:47:59 UTC 2018
> On Dec 9, 2018, at 5:31 PM, Per Liden <per.liden at oracle.com> wrote:
> On 12/09/2018 11:26 PM, Per Liden wrote:
>> On 12/09/2018 11:05 PM, David Holmes wrote:
>>> 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.
Allocation in the constructor might be a mistake if we were ever going
to support VM initialization failure not terminating the process. But
that ship sailed a long time ago, and got about as far as the Vasa :)
> 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.
As noted in the CR, ZGC already does the BarrierSet and thread
creation in the desired order. (Observed both by inspection and
testing.) It was pretty obvious in ZGCs case; the relevant code is
much nicer than for some of the other GCs.
More information about the hotspot-dev