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

[Kim Barrett]

> On Mar 3, 2017, at 4:40 PM, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> On 03/03/2017 10:31 PM, Kim Barrett wrote:
>>> On Mar 3, 2017, at 5:16 AM, Aleksey Shipilev <shade at redhat.com> wrote:
>> 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?
> 
> No, I don't think so. I mean, I get that string-based API is the lesser evil
> here. I am wondering though that if the API expects some predefined strings, it
> is better to have a way to figure out what strings are accepted. I think it is a
> common courtesy for the API to tell that, no matter how internal it is :)
> 
> In current code, this is possible by calling into the actual await_phase(...)
> method, and hoping for the best.
> 
>> 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.
> 
> The example that immediately comes to mind is asserting that a target GC indeed
> supports all the phases you are about to test. Having a 10ms sanity test that
> polls phase name roster and checks everything is available is better than having
> multi-second tries for each phase in turn. Good luck keeping calm debugging a
> test that has a typo in 20th phase name in try order.
> 
> Thanks,
> -Aleksey

If this feature is required to pass review, I can do it, but I'd
prefer not. For the tests I've written so far or know I'll be writing,
the effort involved in creating and maintaining that sort of sanity
check seems not even remotely worth the trouble. I would rather not
add code that I think has a good chance of never being used. It can be
added later if someone really wants it.