RFR(M): 8000244: G1: Ergonomically set MarkStackSize and use virtual space for global marking stack

[John Cuthbertson]

Hi Everyone,

Can I have a couple of volunteers review the change for this CR - the 
webrev can be found at: http://cr.openjdk.java.net/~johnc/8000244/webrev.0/

Summary:
In response code review comments from Bengt for CR 7188263, I decided to 
deal with the marking stack in its own CR - these are those changes.

The allocation of G1's global marking stack now matches that of CMS and 
is allocated from virtual memory instead of C heap. Further the size of 
the marking stack has been changed from a fixed 128*TASKQUEUE_SIZE (16M 
entry capacity in a 64 bit JVM), which is the equivalent of the task 
queues of 128 threads, to a value based upon the actual number of 
parallel marking threads - with a suitable default minimum (4M entry 
capacity in a 64 bit JVM). The 4M entry capacity is the equivalent of 
the task queues for 32 threads.  I have also mimicked CMS and added code 
to expand the marking stack in the event that concurrent marking is 
aborted and restarted due to overflowing the stack. The default maximum 
was the previous fixed value (128*TASKQUEUE_SIZE). Hence we go a maximum 
of 2 expansions before we have a marking stack sized as it was 
previously. Additionally I have rearranged (some of) the ConcurrentMark 
initialization code to (hopefully) make it a bit more robust w.r.t. 
allocation failures.

This CR does not address the allocation of the liveness accounting data 
structures - those will be handled as 7188263.

Testing:
* command line testing with some instrumentation
* GC test suite with a low IHOP, heap and marking verification, and 
forced marking overflows (and instrumentation)
* GC test suite (normal)
* jprt
* refworkload (I didn't see any overflows in my runs, with an 8Gb heap, 
but it could happen).

Thanks,

JohnC