@requires semantics for VM flags
david.holmes at oracle.com
Fri Nov 9 01:18:26 UTC 2018
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 . Boris was seeing the error
when the test was using "@requires foo" but it worked okay when changed
to "@requires foo == true":
> 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???
> -- Jon
> On 11/8/18 2:41 PM, David Holmes wrote:
>> On 7/11/2018 7:01 PM, David Holmes wrote:
>>> 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
>>> @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?
More information about the jtreg-use