@requires semantics for VM flags

[David Holmes]

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":

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???

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
>