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

[Igor Ignatyev]

Hi Volker,

vm.opt.* options are set by jtreg (RegressionContext::processVMOptions), and their value is expected to be "null" if a flag hasn't been passed to JDK under tests via -javaoptions or -vmoptions. I don't think there is something to fix (at least not in jtreg).

-- Igor


> On Oct 11, 2018, at 1:59 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> 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
>>> 
>> 
>>