CODETOOLS-7902290 breaks all JTreg tests which use @requires vm.opt.*

[Jonathan Gibbons]

Volker,

Thanks for the report.  I'll take a look shortly.

-- Jon


On 10/11/18 10:01 AM, Volker Simonis wrote:
> Hi,
>
> the change "CODETOOLS-7902290: introduce error state of @requires
> properties" [1] which was recently pushed to the codetools repo,
> breaks all JTreg tests which have a require clause that queries a non
> final (i.e. no "vm.opt.final") VM option.
>
> For example the test
> "hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java" which
> uses "@requires vm.opt.DeoptimizeALot != true" will now fail with:
>
> test result: Error. Error evaluating expression: name not defined:
> vm.opt.DeoptimizeALot
>
> This is because
> com.sun.javatest.regtest.config.RegressionContext.get() was changed to
> return null instead of the string "null" for unknown properties.
> Looking at requires.VMProps, I realized that "vm.opt.DeoptimizeALot"
> is indeed not defined (as many other "vm.opt" properties, see below).
> So it turns out that all the tests which @required a "vm.opt" option
> did run in a faulty configuration until now.
>
> I could for example easily fix
> "hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java" by adding
> the corresponding option in VMProps.java:
>
> $ hg diff
> diff -r 7a1e2d7ac55a test/jtreg-ext/requires/VMProps.java
> --- a/test/jtreg-ext/requires/VMProps.java      Thu Oct 11 10:11:18 2018 -0400
> +++ b/test/jtreg-ext/requires/VMProps.java      Thu Oct 11 18:51:37 2018 +0200
> @@ -266,6 +266,8 @@
>           vmOptFinalFlag(map, "ClassUnloading");
>           vmOptFinalFlag(map, "UseCompressedOops");
>           vmOptFinalFlag(map, "EnableJVMCI");
> +        String value = String.valueOf(WB.getBooleanVMFlag("DeoptimizeALot"));
> +        map.put("vm.opt.DeoptimizeALot", value);
>       }
>
> Following is a list of all "vm.opt" options used in @requires clauses
> without being defined in VMProps.java:
>
> vm.opt.AggressiveOpts
> vm.opt.ClassUnloading
> vm.opt.ClassUnloadingWithConcurrentMark
> vm.opt.DeoptimizeALot
> vm.opt.DisableExplicitGC
> vm.opt.ExplicitGCInvokesConcurrent
> vm.opt.FlightRecorder
> vm.opt.G1HeapRegionSize
> vm.opt.Inline
> vm.opt.MaxGCPauseMillis
> vm.opt.StartFlightRecording
> vm.opt.SurvivorAlignmentInBytes
> vm.opt.TieredCompilation
> vm.opt.TieredStopAtLevel
> vm.opt.TieredStopAtLevel==4)
> vm.opt.TieredStopAtLevel==null
> vm.opt.UseJVMCICompiler
>
> What's the current plan? Do we want to add all these options in
> VMProps.java? Or should we better add all the -XX VM options together
> to VMProps such that they can all be freely used within @requires
> clauses?
>
> Thank you and best regards,
> Volker
>
> PS: I've noticed that there's "8209807: improve handling exception in
> requires.VMProps" [2] to apparently adapt VMProps.java to
> CODETOOLS-7902290 but I've tried the attached webrev and it doesn't
> help with the described problem.
>
> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902290
> [2] https://bugs.openjdk.java.net/browse/JDK-8209807