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