@requires semantics for VM flags

[Jonathan Gibbons]

On 11/08/2018 05:18 PM, David Holmes wrote:
> Hi Jon,
>
> On 9/11/2018 10:56 AM, Jonathan Gibbons wrote:
>> Regrettably, your naive intuition is incorrect.
>>
>> The current semantics are that if a name is undefined or if the name 
>> is set to a value that is not "true" or "false", then it is not a 
>> boolean value, and so you will get an error.
>
> Hmmm that's not what has been reported [1]. Boris was seeing the error 
> when the test was using "@requires foo" but it worked okay when 
> changed to "@requires foo == true":

I suspect that turns into string comparison, in which case if foo is 
undefined it will be null, and the result of the comparison will be 
false. The same would be true for "@requires foo = false".

>
> http://cr.openjdk.java.net/~bulasevich/8213410/webrev.00/test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java.cdiff.html 
>
>
>> Although I'm not an expert on VM flags, as I understand it, there is 
>> no easy way to tell if a flag should be a boolean value, which makes 
>> it problematic to default unset values to false.
>
> Isn't everything on @requires a boolean expression???

The overall expression is a boolean expression, sure, but the terms 
within the expression need not be.  Fore example,

     @requires os.maxMemory > 4G

Also, see these lines from the tag spec: 
https://openjdk.java.net/jtreg/tag-spec.html


||

	
|vm.opt./switch/| 	A boolean VM option, derived from option 
|-XX:+/switch/| or |-XX:-/switch/| 	|true| |false| 	
|vm.opt./name/| 	A VM option, derived from option |-XX:/name/=/value/| 
|/value/|



Generally, handling the vm options is difficult, not least because of 
the way the VM interprets the options, meaning that sometimes it will 
ignore them altogether: so testing for the presence of an option on the 
command line is a weak almost-useless check. Although I defer to folk 
like Igor who helped design a lot of this stuff, my recommendation is to 
stay clear of vm.opt.* and to use the "extraPropDefns" mechanism that 
allows you to test the configuration values *after* they have been 
analyzed by the VM.


-- Jon

>
> Thanks,
> David
>
> [1] 
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-November/035058.html
>
>> -- Jon
>>
>>
>> On 11/8/18 2:41 PM, David Holmes wrote:
>>> Ping!
>>>
>>> Thanks,
>>> David
>>>
>>> On 7/11/2018 7:01 PM, David Holmes wrote:
>>>> Hi,
>>>>
>>>> Can you clarify the intended semantics for @requires when 
>>>> referencing a VM flag. It seems the current behaviour is:
>>>>
>>>> @requires foo -> foo must exist and == true
>>>> @requires !foo -> foo must exist and == false
>>>> @requires foo == true -> IF foo exists then it == true
>>>> @requires foo == false -> IF foo exists then it == false
>>>>
>>>> I would have naively expected:
>>>>
>>>> @requires foo
>>>>
>>>> and
>>>>
>>>> @requires foo == true
>>>>
>>>> to be semantically identical?
>>>>
>>>> Follow up question: if there are multiple @requires are they 
>>>> evaluated using short-circuit logic ie:
>>>>
>>>> @requires vm.bits == 64
>>>> @requires VMFlagOnlyFor64Bits
>>>>
>>>> will not look for the flag if running on a 32-bit system?
>>>>
>>>> Thanks,
>>>> David
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/jtreg-use/attachments/20181108/9fa4a468/attachment.html>