The global G1SATBMarkQueueSet and DirtyCardQueueSet are defined as static variables in G1BarrierSet. (There is a second, non-static, DCQS in G1CollectedHeap.) As a result, they are constructed and destructed during static initializer / destructor time.

This complicates their initialization, since we can't make use of much of anything at that point, not even command line option values. Hence the two-stage construction pattern for these objects that could be simplified or eliminated if they were allocated normally.

It also risks destructor order problems during process shutdown. For example, while testing changes for JDK-8209345 I noticed a couple of otherwise unknown and unexplained errors about calling a pure virtual function. I haven't been able to reproduce these, but I think the problem is that we have run the destructor for the static queue set before some thread has finished terminating. The terminating thread then attempts to flush (including filtering) its thread-local SATBMarkQueue, invoking the qset's (virtual after JDK-8209345) filter function. Without the proposed fix for JDK-8209345 this ordering problem is "benign" in that flushing the queue after the qset has been destroyed pilfers through the corpse of the qset for various values that just happen to still be there.