RFR: 8320750: Allow a testcase to run with muliple -Xlog

[David Holmes]

On Mon, 27 Nov 2023 13:32:52 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Running a testcase with muliple -Xlog crashes JTREG test cases. This is because `Collector.toMap` is not given a merge strategy.
> 
> When the same argument is passed multiple times, I have added a merge strategy to use the latter value. This is similar to how it is implemented for `vm.opt.*` in JTREG.
> 
> If the flag tested is `-Xlog`, replace the value part with a dummy value "NONEMPTY_TEST_SENTINEL". This is because in the case of multiple `-Xlog` all values are used, and JTREG does not give a satisfactory way to represent them. This dummy value should make it hard to try to `@require` on specific values by mistake.
> 
> Tested with:
> 
>  @requires vm.opt.x.Xlog == "NONEMPTY_TEST_SENTINEL"
>  @requires vm.opt.x.Xlog == "NONEMPTY_TEST_SENTINELXXX"
>  @requires vm.opt.x.Xms == "3g"
> 
> and
> 
> JAVA_OPTIONS=-Xms3g -Xms4g
> JAVA_OPTIONS=-Xms4g -Xms3g
> JAVA_OPTIONS=-Xlog:gc* -Xlog:gc*
> ``` 
> 
> Running tier1

The VM processes -XX flags such that "last value wins" - though in part that is due to convention in that the nature of our flags tend to be absolute rather than relative (e.g. imagine a flag `-XX:IncreaseDefaultFoo=3G` that simply does `foo_size += 3 * G` - there we would not have a last-flag-wins situation).

The -X and other flags are a mixed bunch and there are no generally applicable rules.

I struggle to see the actual benefit of `@requires vm.opt.x.Foo` as a general mechanism because I don't think there are many flags that would reasonably be applied to test runs that individual tests would care that much about ( things like Xcomp are already handled directly). We do not expect that any test can be run with any set of incoming flags - we only deal with specific sets of flags to control specific areas of functionality. E.g if someone complains that a test times out because they passed `-Xint` the solution  would be "well don't do that" - we don't have the resources to try and make every test bullet-proof.

The -Xlog handling for example, I can't see any case where a test should care about any incoming logging flags - even if the test itself performs logging, it should not care about other logging settings - and we would fix the test if there was a specific problem. 

Even for the heap flags I'm struggling to see the usefulness. If a test has specific heap size requirements then the test should set them - and last setting wins, so should be no issue there (I suspect many tests are lazy though and assume defaults so for example a test may set -Xmx without -Xms and so an externally supplied -Xms may conflict with it - but in that case I'd question why anyone was forcing -Xms externally like that) . 

Taking a specific example, to me `test/hotspot/jtreg/gc/arguments/TestG1HeapSizeFlags.java` that you changed is a clear candidate for vm.flagless and not using CreateTestJVM because this test is only checking the affects of it setting specific GC flags - we don't (or shouldn't care) about running such a simple test with a range of VM flags because the test itself is not interesting enough to warrant it i.e. there is nothing about that test to make us think it contains something unique such that only that test will provide test coverage in a specific area in relation to externally set flags. I mean that is what the whole push to `@driver` and `vm.flagless` has been about - there is no value in running a whole bunch of tests with other flags, given what the tests are actually testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16824#issuecomment-1832911919