RFR: 8154096: Extend WhiteBox API with methods which retrieve from VM information about available GC

[Dmitry Fazunenko]

Kim,

thanks for the review. Please find comments below.


On 18.05.2016 1:00, Kim Barrett wrote:
>> On May 10, 2016, at 2:37 PM, Dmitry Fazunenko <dmitry.fazunenko at oracle.com> wrote:
>>
>> Kim,
>>
>> I've fixed all your comments:
>>   http://cr.openjdk.java.net/~dfazunen/8154096/webrev.03/
>>   http://cr.openjdk.java.net/~dfazunen/8154096/webrev.02vs03/
> Thanks, those changes are good.
>
>> Answering your question I copy my previous answer:
>>
>>> ------------------------------------------------------------------------------
>>>
>>> Looking at the JDK-8154096 and the CRs it is blocking, I'm failing to
>>> understand the motivation for the "selected by ergonomics" predicate.
>>> Why is ergo-selection more interesting than command-line or default
>>> selection?  And for the described use-case (jtreg @requires
>>> filtering), why would any of those distinctions be interesting?
>>>
>>> ------------------------------------------------------------------------------
>>
>> This is needed to check the ability to set an alternative collector in the next VM start.
>> How the 'vm.gc' @requires properties is setting now:
>> jtreg parses given VM flags  for -XX:+Use(.*)GC  pattern. If no matches found, 'vm.gc' will be set to null, which means: all tests for any collector are applicable. If user specified -XX:+UseParallelGC, jtreg will set 'vm.gc' to Parallel, that means that only tests which set Parallel collector or do not set any collector are applicable.
>> This approach has disadvantages:
>> - on some VMs (like minimal), giving -XX:+UseParallelGC will not have any effect, Serial will be used anyway.
>>   but jtreg is now aware of this, so 'vm.gc' will be set to Parallel
>> - If a GC has a mode which is turned like: -XX:+UseG1GC -XX:+UseModeOfG1GC,
>>   jtreg will not be able to handle that correctly, so  'vm.gc' will be set to either G1 or ModeOfG1 (depending on the flag order)
>>
>> Incorrect setting of 'vm.gc' will cause situations when some tests are executed in inappropriate configurations and fail.
>>
>> To address the issues like that, jtreg now allows a custom code to be executed prior the tests.
>> This delegates the responsibility on @requires property setting to test suites.
>> So now we need to write a code to decide whether a collector X could be set or not.
>> The collector X could be set if:
>>   (currentGC == X) | (X isSupportedGC() && currentGC.isSelectedByErgo)
>> For that purpose we need to distinguish cases when the current collector is set by user or selected by ergo.
> Thanks for the explanation. Then I think my problem with
> isSelectedByErgo might be more of a naming issue.  The question being
> asked is something like
>
>    Was the current collector directly requested by the user (via
>    command line arguments or other means)?
>
> Or alternatively
>
>    Was the current collector selected through some other means, in the
>    absence of a direct request.
>
> And "directly requested" doesn't necessarily mean only -XX:+UseXXXGC.
> There may be options that are only valid with a specific GC, whose use
> might be taken to imply the use of that GC.
>
> isSelectedByErgo is asking the second question. I think I'd prefer a
> predicate that asked the first. In particular, "ergo" is jargon, and
> potentially confusing. For example, the VM argument processing admits
> to three states: command-line, ergo, or default. Does default fall
> under this predicate? Well, it appears the VM argument processing
> doesn't use the default state for the GC selection options, but that's
> hardly obvious.

Yes, the name might be not optimal. If you have better suggestions I 
will rename.
But please not, this API is not for direct use by developers. We need it 
to set properly
some @requires variables.


Thanks,
Dima