<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 11/08/2018 05:18 PM, David Holmes
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:fb859953-3e2c-0be3-87b9-cf7ae1fe3f7f@oracle.com">Hi Jon,
      <br>
      <br>
      On 9/11/2018 10:56 AM, Jonathan Gibbons wrote:
      <br>
      <blockquote type="cite">Regrettably, your naive intuition is
        incorrect.
        <br>
        <br>
        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.
        <br>
      </blockquote>
      <br>
      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":
      <br>
    </blockquote>
    <br>
    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".<br>
    <br>
    <blockquote type="cite"
      cite="mid:fb859953-3e2c-0be3-87b9-cf7ae1fe3f7f@oracle.com">
      <br>
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~bulasevich/8213410/webrev.00/test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java.cdiff.html">http://cr.openjdk.java.net/~bulasevich/8213410/webrev.00/test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java.cdiff.html</a>
      <br>
      <br>
      <blockquote type="cite">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.
        <br>
      </blockquote>
      <br>
      Isn't everything on @requires a boolean expression???
      <br>
    </blockquote>
    <br>
    The overall expression is a boolean expression, sure, but the terms
    within the expression need not be.  Fore example,  <br>
        <br>
        @requires os.maxMemory > 4G<br>
    <br>
    Also, see these lines from the tag spec:
    <a class="moz-txt-link-freetext" href="https://openjdk.java.net/jtreg/tag-spec.html">https://openjdk.java.net/jtreg/tag-spec.html</a><br>
    <br>
    <br>
    <code></code>
    <table summary="Supported names for @requires">
      <tbody>
        <tr>
          <td><br>
          </td>
          <td><br>
          </td>
        </tr>
        <tr>
          <td><code>vm.opt.<i>switch</i></code></td>
          <td>A boolean VM option, derived from option
            <code>-XX:+<i>switch</i></code> or
            <code>-XX:-<i>switch</i></code></td>
          <td><code>true</code> <code>false</code></td>
          <td><br>
          </td>
        </tr>
        <tr>
          <td><code>vm.opt.<i>name</i></code></td>
          <td>A VM option, derived from option
            <code>-XX:<i>name</i>=<i>value</i></code></td>
          <td><code><i>value</i></code></td>
        </tr>
      </tbody>
    </table>
    <br>
    <br>
    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.<br>
    <br>
    <br>
    -- Jon<br>
    <br>
    <blockquote type="cite"
      cite="mid:fb859953-3e2c-0be3-87b9-cf7ae1fe3f7f@oracle.com">
      <br>
      Thanks,
      <br>
      David
      <br>
      <br>
      [1]
<a class="moz-txt-link-freetext" href="http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-November/035058.html">http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-November/035058.html</a><br>
      <br>
      <blockquote type="cite">-- Jon
        <br>
        <br>
        <br>
        On 11/8/18 2:41 PM, David Holmes wrote:
        <br>
        <blockquote type="cite">Ping!
          <br>
          <br>
          Thanks,
          <br>
          David
          <br>
          <br>
          On 7/11/2018 7:01 PM, David Holmes wrote:
          <br>
          <blockquote type="cite">Hi,
            <br>
            <br>
            Can you clarify the intended semantics for @requires when
            referencing a VM flag. It seems the current behaviour is:
            <br>
            <br>
            @requires foo -> foo must exist and == true
            <br>
            @requires !foo -> foo must exist and == false
            <br>
            @requires foo == true -> IF foo exists then it == true
            <br>
            @requires foo == false -> IF foo exists then it == false
            <br>
            <br>
            I would have naively expected:
            <br>
            <br>
            @requires foo
            <br>
            <br>
            and
            <br>
            <br>
            @requires foo == true
            <br>
            <br>
            to be semantically identical?
            <br>
            <br>
            Follow up question: if there are multiple @requires are they
            evaluated using short-circuit logic ie:
            <br>
            <br>
            @requires vm.bits == 64
            <br>
            @requires VMFlagOnlyFor64Bits
            <br>
            <br>
            will not look for the flag if running on a 32-bit system?
            <br>
            <br>
            Thanks,
            <br>
            David
            <br>
          </blockquote>
        </blockquote>
        <br>
      </blockquote>
    </blockquote>
    <br>
  </body>
</html>