<div dir="ltr"><div>Yes, they should behave the same.</div><div><br></div><div>Cheers, Thomas</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Dec 1, 2025 at 10:41 AM Frederic Thevenet <<a href="mailto:fthevene@redhat.com">fthevene@redhat.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">Thanks for filling the bug, David; I've assigned it to myself and will <br>
propose a PR for this shortly.<br>
<br>
Before I do, there's one point I feel might be worth clarifying in this <br>
discussion first.<br>
In the current implementation, PrintFlagsFinal and PrintFlagsRanges are <br>
quite tightly intertwined, as one acts as an "upgrade" to the other <br>
(i.e. setting PrintFlagsRanges will override PrintFlagsFinal).<br>
To me, it makes sense to change the behaviour for PrintFlagsRanges to <br>
also print all flags if we do it for PrintFlagsFinal, but I wanted to <br>
first ask if anyone sees a reason not to do this?<br>
<br>
Cheers<br>
Frederic<br>
<br>
On 12/1/25 10:21, David Holmes wrote:<br>
> Okay I have filed:<br>
><br>
> JDK-8372802: PrintFlagsFinal should also print locked flags<br>
><br>
> but note there is no commitment for anyone to actually perform the work.<br>
><br>
> David<br>
><br>
> On 28/11/2025 3:19 pm, Thomas Stüfe wrote:<br>
>> I am very much in favor of printing all flags, for the reasons <br>
>> Frederic has given. When one supports many different releases, it is <br>
>> a huge timesaver not to have to look up flags but see them right <br>
>> there in the customer logs. The ability of PrintFlagsFinal to give me <br>
>> all flags, including default values, after they are resolved to their <br>
>> final values, is also very useful during development.<br>
>><br>
>> For simplicity, I would prefer just to change the behavior of <br>
>> PrintFlagsFinal to do that, but I could live with a new <br>
>> PrintAllFlagsFinal.<br>
>><br>
>> Number of normal flags: 513, incl. diagnostic: 777, incl. <br>
>> experimental&diagnostic: 933. (Jdk 25). So, it's a bit more. I am not <br>
>> bothered by this, since this list never fits onto a single screen <br>
>> anyway. People grep. But if others prefer an extra flag, sure, <br>
>> let's have one.<br>
>><br>
>><br>
>> On Thu, Nov 27, 2025 at 3:05 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 27/11/2025 12:53 am, Frederic Thevenet wrote:<br>
>>      > Hi,<br>
>>      ><br>
>>      > Currently, using +PrintFlagsFinal prints out all JVM flags and <br>
>> their<br>
>>      > values, even if they were not modified from their default, except<br>
>>     for<br>
>>      > 'locked' flags, i.e. Experimental and Diagnotic flags. In order<br>
>>     to have<br>
>>      > those printed out as well, one must first 'unlock' them (with<br>
>>      > +UnlockExperimentalVMOptions, for instance).<br>
>><br>
>>     I think this was simply a pragmatic decision to avoid <br>
>> overwhelming the<br>
>>     user with information that should not be relevant.<br>
>>      > Now, is their a strong reason for not always displaying the <br>
>> default<br>
>>      > values for those in scenarios were there is no concerns that the<br>
>>     output<br>
>>      > might be too large (that is when calling upon<br>
>>     'JVMFlag::printFlags' with<br>
>>      > 'skipDefaults' set to false, like PrintFlagsFinal does)?<br>
>>      ><br>
>>      > The reason for this question is that when chasing a bug in <br>
>> scenarios<br>
>>      > where one can only rely on logs or output provided by tools that<br>
>>     uses<br>
>>      > +PrintFlagsFinal, getting the default values *in the <br>
>> conditions that<br>
>>      > those logs where produced* can be tricky as it depends on the <br>
>> exact<br>
>>      > version of the JDK that was running, and some values can be<br>
>>     changed by<br>
>>      > ergonomics.<br>
>><br>
>>     Ouch. I think that would be a poor design choice for diagnostic, and<br>
>>     especially experimental flags!<br>
>><br>
>><br>
>> Not every experimental/diagnostic flag is a boolean that defaults to <br>
>> false and controls an opt-in feature. We have non-boolean <br>
>> experimental flags and boolean flags that default to true. It is not <br>
>> unthinkable that those are changed during VM start.<br>
>><br>
>><br>
>>      > If you need to know the default for experimental flags -- which<br>
>>     given<br>
>>      > their nature can and do change often -- your choices are to<br>
>>     either ask<br>
>>      > for these logs to be generated again using<br>
>>     +UnlockExperimentalVMOptions<br>
>>      > (even if there is no intention of changing an experimental flag)<br>
>>     or to<br>
>>      > go on a time consuming deep dive into the code base for the exact<br>
>>      > version of the JDK that was used. Neither is ideal.<br>
>><br>
>>     True, but for experimental flags in particular, unless you are deep<br>
>>     diving into the code how can you know whether a particular flag <br>
>> and its<br>
>>     value are relevant to your debugging in the first place?<br>
>><br>
>><br>
>> I think the point here is reducing analyst strain. It's not that it <br>
>> is impossible to get the information otherwise, but that <br>
>> it's convenient and stress-reducing to have one sure way to look up <br>
>> all resolved flag values for a customer's JVM run. Folks who have to <br>
>> work with many cases involving different JVM versions would value this.<br>
>><br>
>> BTW, we do print default values for non-experimental non-diagnostic <br>
>> flags, too. The same reasoning applies here: if its not changed, you <br>
>> could look up the default value.<br>
>><br>
>><br>
>>     That said, I don't see any harm in providing a way to print all <br>
>> flags,<br>
>>     though whether by default or by a new -XX:PrintAllFlagsFinal <br>
>> flag, I'm<br>
>>     not sure.<br>
>><br>
>><br>
>> Wonderful, let's do that then.<br>
>><br>
>> Cheers, Thomas<br>
><br>
<br>
-- <br>
Frederic Thevenet<br>
Senior Software Engineer - OpenJDK<br>
Red Hat France <<a href="https://www.redhat.com" rel="noreferrer" target="_blank">https://www.redhat.com</a>><br>
BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92<br>
<br>
<br>
</blockquote></div>