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

[Volker Simonis]

Jonathan Gibbons <jonathan.gibbons at oracle.com> schrieb am Do. 11. Okt. 2018
um 19:16:

> Volker,
>
> It's a typo/oops on my part.  I'll fix it.
>

Hi John,

thanks for looking at this issue!

What do you mean  with “ typo”? Returning null instead of the string “null”?

That would “fix” the corresponding tests in the sense that they would run
again, however still with bogus results for all the @requires guards which
 check the “vm.opt.*” options. Shouldn’t we fix that as well?

Regards,
Volker



> -- Jon
>
>
> On 10/11/18 10:13 AM, Jonathan Gibbons wrote:
> > 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
> >
>
>