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

This seems a rather fragile mechanism. In practice I expect there are only a handful of -X flags tests really care about - and some of them already handled (e.g. -Xint, -Xmixed,-Xcomp are exposed by the vm.mode value). Merging requires you to know how the launcher and VM would process things and it is different for different things. So what you have now acts as "last one wins" with a special case for -Xlog such that only its presence can be detected not its value (not a loss I think).

It seems like this fixes the bug your original code had, but I can't review it as I don't understand the actual code involved.

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

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