<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 2, 2023 at 5:30 AM David Holmes <<a href="mailto:david.holmes@oracle.com">david.holmes@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 1/02/2023 7:48 pm, Thomas Stüfe wrote:<br>
> On Wed, Feb 1, 2023 at 5:24 AM David Holmes <<a href="mailto:david.holmes@oracle.com" target="_blank">david.holmes@oracle.com</a> <br>
> <mailto:<a href="mailto:david.holmes@oracle.com" target="_blank">david.holmes@oracle.com</a>>> wrote:<br>
> <br>
>     On 1/02/2023 5:23 am, Ioi Lam wrote:<br>
>      > CC-ing hotspot-dev for wider discussion.<br>
>      ><br>
>      > On 1/31/2023 12:43 AM, Thomas Stüfe wrote:<br>
>      >> Hi Ioi,<br>
>      >><br>
>      >> a short question. You did the JVM flag handling revamp, right?<br>
>      >><br>
>      >> I recently ran into a weird problem where FLAG_SET_ERGO would not<br>
>      >> work, turned out it ends up using the constraint function, which<br>
>      >> silently refused to set the argument if the argument violates the<br>
>      >> constraint.<br>
>      >><br>
>      >> That makes perfect sense, I had an error in my code. But if we<br>
>     set a<br>
>      >> flag with ERGO origin, we set it in the JVM, and the JVM should<br>
>     adhere<br>
>      >> to constraints, not doing so is a programming error and I would<br>
>     expect<br>
>      >> an assert here. The same logic may be applied to other origins too,<br>
>      >> e.g. DEFAULT.<br>
>      >> Do you think this makes sense?<br>
>      >><br>
>      >> BTW I added debug output (setting verbose to true for ERGO), and<br>
>     I see<br>
>      >> other flag's ergonomics also getting ignored, which would have<br>
>     to be<br>
>      >> fixed too.<br>
>      >><br>
>      >> Cheers, Thomas<br>
>      >><br>
>      ><br>
>      ><br>
>      > This problem is also reported in<br>
>      > <a href="https://bugs.openjdk.org/browse/JDK-8224980" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8224980</a><br>
>     <<a href="https://bugs.openjdk.org/browse/JDK-8224980" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8224980</a>><br>
>      ><br>
>      > There are proposals for making the debug message more obvious,<br>
>     and/or<br>
>      > assert().<br>
>      ><br>
>      > Currently we don't have documentation of what the caller of<br>
>      > FLAG_SET_ERGO is supposed to do.<br>
>      ><br>
>      > There are 3 ways to set a flag. The current behavior of the<br>
>     following<br>
>      > two ways seems reasonable<br>
>      ><br>
>      >     FLAG_SET_CMDLINE - rejects user input and exit VM<br>
>      >     FLAG_SET_MGMT    - return JVMFlag::Error<br>
>      ><br>
>      > With command-line, the user should inspect the limits for the<br>
>     current<br>
>      > environment and restart the app with an appropriate value<br>
>      ><br>
>      > With FLAG_SET_MGMT, I suppose it's similar -- whoever is using the<br>
>      > management API should detect the error and adjust their parameter<br>
>     values<br>
>      > (by hand, or programmatically)<br>
>      ><br>
>      > However, FLAG_SET_ERGO also returns JVMFlag::Error, but I don't<br>
>     see any<br>
>      > of our code checking for the return value. So the unwritten<br>
>     convention<br>
>      > is that the call must not fail.<br>
>      > However, if the specified value is out of range, should we abort<br>
>     the VM,<br>
>      > ignore the value, or cap the value? E.g., if the range is 0~100,<br>
>     but you<br>
>      > call SET_ERGO with 101, should we cap the value to 100?<br>
> <br>
>     Generally if our code tries to sets a flags value to something invalid<br>
>     that is a programming error that should be reported right away. If the<br>
>     value is a "constant" then we should just assert that setting the value<br>
>     worked. If the value is determined by external factors that might vary<br>
>     at runtime (so no guarantee the end result will be valid) then we<br>
>     should<br>
>     have logic that can correct for the invalid value (or we should change<br>
>     the way we do the calculation).<br>
> <br>
> <br>
> Agreed, but how do you want to tell them apart?<br>
<br>
That would have to be determined case-by-case. For each ergo flag we <br>
would have to decide what value it is calculating and based on what, and <br>
determine whether an out-of-range value is an error or something to be <br>
wary of.<br></blockquote><div><br></div><div>Sure, what I meant was how to control it? Two sets of FLAT_SET_... macros, one that asserts on constraint violation, one that caps?</div><div><br></div><div><br></div><div>Cheers, Thomas <br></div></div></div>