10 RFR: 8169517: WhiteBox should provide concurrent GC phase control

[Kim Barrett]

> On Mar 3, 2017, at 5:16 AM, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> On 03/03/2017 10:59 AM, Kim Barrett wrote:
>> Looking for reviewers.
>> 
>>> Webrev:
>>> http://cr.openjdk.java.net/~kbarrett/8169517/hs.00/
>>> http://cr.openjdk.java.net/~kbarrett/8169517/hotspot.00/
> 
> I can see how that can be helpful. We will probably try to adapt this to
> Shenandoah too, once we pull this into Shenandoah forest.
> 
> Comments:
> 
> *) Purely string-based interface makes me itchy. If we follow this route,
> shouldn't the collector report what phases it supports? Otherwise, testers would
> have to end up polling the phases looking for "false", and before that, looking
> into the GC code to figure out phase names. Given that proposed G1 code already
> builds const char* const names[], could it report it via Whitebox too?
> 
> Otherwise looks good. Time will tell if that was a good idea :)
> 
> Thanks,
> -Aleksey

Thanks for your review. I'll be interested in how the Shenandoah
adaptation goes.

Regarding the string-based API, this is a white box API after all.
Doing something else, like an enum in the whitebox code, seemed to
require maintaining information both in the whitebox code and in the
various GCs. And which GCs should be supported by the whitebox code?
Should the Shenandoah phase identifiers be there, for example?

I thought about a function to return the set of valid phase names, but
couldn't come up with a good use for it.  One can't write a test that
just iterates through the phases, requesting each in turn.  A phase
might not be reachable without additional setup; there is at least one
phase like that in G1 already.