@requires semantics for VM flags

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

@requires semantics for VM flags

David Holmes
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
Reply | Threaded
Open this post in threaded view
|

Re: @requires semantics for VM flags

David Holmes
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
Reply | Threaded
Open this post in threaded view
|

Re: @requires semantics for VM flags

Jonathan Gibbons
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.

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.

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

Reply | Threaded
Open this post in threaded view
|

Re: @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
>
Reply | Threaded
Open this post in threaded view
|

Re: @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


Reply | Threaded
Open this post in threaded view
|

Re: @requires semantics for VM flags

Volker Simonis
Hi David,

have you read the recent thread [1] and especially my mail [2] where I
discussed some similar problems (especially "vm.opt" vs.
"vm.opt.final") ? I think there's big confusion about the semantics of
these options.

Regards,
Volker

[1] http://mail.openjdk.java.net/pipermail/code-tools-dev/2018-October/000448.html
[2] http://mail.openjdk.java.net/pipermail/code-tools-dev/2018-October/000452.html


On Fri, Nov 9, 2018 at 3:12 AM Jonathan Gibbons
<[hidden email]> wrote:

>
>
>
> 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
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: @requires semantics for VM flags

David Holmes
Hi Volker,

On 9/11/2018 8:17 PM, Volker Simonis wrote:
> Hi David,
>
> have you read the recent thread [1] and especially my mail [2] where I
> discussed some similar problems (especially "vm.opt" vs.
> "vm.opt.final") ? I think there's big confusion about the semantics of
> these options.

No I'm not on code-tools-dev so had not seen this.

I agree this seems to be a mess. There seems to be an
expectation/assumption that you can use @requires with any vm flag, when
that is simply not true. The mechanism seems to be being used incorrectly.

David

> Regards,
> Volker
>
> [1] http://mail.openjdk.java.net/pipermail/code-tools-dev/2018-October/000448.html
> [2] http://mail.openjdk.java.net/pipermail/code-tools-dev/2018-October/000452.html
>
>
> On Fri, Nov 9, 2018 at 3:12 AM Jonathan Gibbons
> <[hidden email]> wrote:
>>
>>
>>
>> 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
>>
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: @requires semantics for VM flags

Jonathan Gibbons
Volker, David,

Volker, since you are referencing those earlier emails of yours, I will
note again that the issue in the subject line was a transient problem
that has now been fixed.

As to the underlying problem, I agree that it's a bit of a mess, but
while we could maybe improve jtreg a bit in this area, there's not a
whole lot we can do.The bottom line is that using VM options in
@requires is problematic, because it is hard to determine the exact
effect of each option.

As an example, when I wrote the jtreg code for @requires, I wanted to
write tests for the feature, including tests for the vm.opt.* feature. 
Given that jtreg gets tested on many JDK versions and platforms, I was
looking for an option that would work in many/most cases. I settled on
the -server/-client options, but then ran into the issue that these
options may be *quietly ignored* by the VM if they are not supported. 
This means that you cannot determine the effect of an option from
looking at the option alone.

The net outcome was that as a result of the problems with vm.opts.*, we
put in the extraPropDefns feature, so that @requires could test
better-specified properties determined within a running JDK. I would
recommend anyone wanting to test VM characteristics in @requires to
consider testing properties defined by the extraPropDefns code.

-- Jon


On 11/09/2018 04:11 AM, David Holmes wrote:

> Hi Volker,
>
> On 9/11/2018 8:17 PM, Volker Simonis wrote:
>> Hi David,
>>
>> have you read the recent thread [1] and especially my mail [2] where I
>> discussed some similar problems (especially "vm.opt" vs.
>> "vm.opt.final") ? I think there's big confusion about the semantics of
>> these options.
>
> No I'm not on code-tools-dev so had not seen this.
>
> I agree this seems to be a mess. There seems to be an
> expectation/assumption that you can use @requires with any vm flag,
> when that is simply not true. The mechanism seems to be being used
> incorrectly.
>
> David
>
>> Regards,
>> Volker
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/code-tools-dev/2018-October/000448.html
>> [2]
>> http://mail.openjdk.java.net/pipermail/code-tools-dev/2018-October/000452.html
>>
>>
>> On Fri, Nov 9, 2018 at 3:12 AM Jonathan Gibbons
>> <[hidden email]> wrote:
>>>
>>>
>>>
>>> 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
>>>
>>>
>>>