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

[John Cuthbertson]

Hi Everyone,

I have a new webrev based upon comments and observations from Jon 
Masamitsu and Peter Kessler which can be found at: 
http://cr.openjdk.java.net/~johnc/8000244/webrev.1/

Thanks,

JohnC

On 10/02/12 15:45, John Cuthbertson wrote:
> 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