@requires semantics for VM flags
Jonathan Gibbons
jonathan.gibbons at oracle.com
Fri Nov 9 18:54:11 UTC 2018
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
>> <jonathan.gibbons at oracle.com> 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
>>>
>>>
>>>
More information about the jtreg-use
mailing list