RFR(M): 8000244: G1: Ergonomically set MarkStackSize and use virtual space for global marking stack
john.cuthbertson at oracle.com
Thu Dec 6 12:10:55 PST 2012
Thanks for looking over the code again.
I've submitted 8004669 to track the reuse enhancement and I've attached
>> To reuse the previous space we need to cache the ReservedSpace in the
>> CMMarkStack instance to re-initialize the _virtual_space. As a result
>> we need to provide a default constructor for ReservedSpace.
> If we move the code in CMMarkStack::allocate() into the constructor of
> CMMarkStack we would not need to add a default consturctor to
> ReservedSpace. I kind of think it would be more natural to have the
> setup in the constructor anyway.
>> Another concern is that I'm not sure that re-committing the original
>> unexpanded space won't cause a problem on some platforms. I've tested
>> the code with forced re-commits and it seems to work but would rather
>> it was pushed as a separate change.
> Pushing it as a separate change is definitely a good idea. If
> re-committting does not work on a particular platform I guess we are
> just back to the old behaviour, right? That a failed expand of the
> mark stack will exit the VM.
That's the idea and the code new code in CMMarkStack::expand() should do
that. I've also added the above comments to the CR.
More information about the hotspot-gc-dev