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

[Kim Barrett]

> 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.