@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