Any reason why +PrintFlagsFinal requires unlocking experimental and diagnostic flags to print their default values?

[Frederic Thevenet]

Thanks for filling the bug, David; I've assigned it to myself and will 
propose a PR for this shortly.

Before I do, there's one point I feel might be worth clarifying in this 
discussion first.
In the current implementation, PrintFlagsFinal and PrintFlagsRanges are 
quite tightly intertwined, as one acts as an "upgrade" to the other 
(i.e. setting PrintFlagsRanges will override PrintFlagsFinal).
To me, it makes sense to change the behaviour for PrintFlagsRanges to 
also print all flags if we do it for PrintFlagsFinal, but I wanted to 
first ask if anyone sees a reason not to do this?

Cheers
Frederic

On 12/1/25 10:21, David Holmes wrote:
> Okay I have filed:
>
> JDK-8372802: PrintFlagsFinal should also print locked flags
>
> but note there is no commitment for anyone to actually perform the work.
>
> David
>
> On 28/11/2025 3:19 pm, Thomas Stüfe wrote:
>> I am very much in favor of printing all flags, for the reasons 
>> Frederic has given. When one supports many different releases, it is 
>> a huge timesaver not to have to look up flags but see them right 
>> there in the customer logs. The ability of PrintFlagsFinal to give me 
>> all flags, including default values, after they are resolved to their 
>> final values, is also very useful during development.
>>
>> For simplicity, I would prefer just to change the behavior of 
>> PrintFlagsFinal to do that, but I could live with a new 
>> PrintAllFlagsFinal.
>>
>> Number of normal flags: 513, incl. diagnostic: 777, incl. 
>> experimental&diagnostic: 933. (Jdk 25). So, it's a bit more. I am not 
>> bothered by this, since this list never fits onto a single screen 
>> anyway. People grep. But if others prefer an extra flag, sure, 
>> let's have one.
>>
>>
>> On Thu, Nov 27, 2025 at 3:05 AM David Holmes <david.holmes at oracle.com 
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     On 27/11/2025 12:53 am, Frederic Thevenet wrote:
>>      > Hi,
>>      >
>>      > Currently, using +PrintFlagsFinal prints out all JVM flags and 
>> their
>>      > values, even if they were not modified from their default, except
>>     for
>>      > 'locked' flags, i.e. Experimental and Diagnotic flags. In order
>>     to have
>>      > those printed out as well, one must first 'unlock' them (with
>>      > +UnlockExperimentalVMOptions, for instance).
>>
>>     I think this was simply a pragmatic decision to avoid 
>> overwhelming the
>>     user with information that should not be relevant.
>>      > Now, is their a strong reason for not always displaying the 
>> default
>>      > values for those in scenarios were there is no concerns that the
>>     output
>>      > might be too large (that is when calling upon
>>     'JVMFlag::printFlags' with
>>      > 'skipDefaults' set to false, like PrintFlagsFinal does)?
>>      >
>>      > The reason for this question is that when chasing a bug in 
>> scenarios
>>      > where one can only rely on logs or output provided by tools that
>>     uses
>>      > +PrintFlagsFinal, getting the default values *in the 
>> conditions that
>>      > those logs where produced* can be tricky as it depends on the 
>> exact
>>      > version of the JDK that was running, and some values can be
>>     changed by
>>      > ergonomics.
>>
>>     Ouch. I think that would be a poor design choice for diagnostic, and
>>     especially experimental flags!
>>
>>
>> Not every experimental/diagnostic flag is a boolean that defaults to 
>> false and controls an opt-in feature. We have non-boolean 
>> experimental flags and boolean flags that default to true. It is not 
>> unthinkable that those are changed during VM start.
>>
>>
>>      > If you need to know the default for experimental flags -- which
>>     given
>>      > their nature can and do change often -- your choices are to
>>     either ask
>>      > for these logs to be generated again using
>>     +UnlockExperimentalVMOptions
>>      > (even if there is no intention of changing an experimental flag)
>>     or to
>>      > go on a time consuming deep dive into the code base for the exact
>>      > version of the JDK that was used. Neither is ideal.
>>
>>     True, but for experimental flags in particular, unless you are deep
>>     diving into the code how can you know whether a particular flag 
>> and its
>>     value are relevant to your debugging in the first place?
>>
>>
>> I think the point here is reducing analyst strain. It's not that it 
>> is impossible to get the information otherwise, but that 
>> it's convenient and stress-reducing to have one sure way to look up 
>> all resolved flag values for a customer's JVM run. Folks who have to 
>> work with many cases involving different JVM versions would value this.
>>
>> BTW, we do print default values for non-experimental non-diagnostic 
>> flags, too. The same reasoning applies here: if its not changed, you 
>> could look up the default value.
>>
>>
>>     That said, I don't see any harm in providing a way to print all 
>> flags,
>>     though whether by default or by a new -XX:PrintAllFlagsFinal 
>> flag, I'm
>>     not sure.
>>
>>
>> Wonderful, let's do that then.
>>
>> Cheers, Thomas
>

-- 
Frederic Thevenet
Senior Software Engineer - OpenJDK
Red Hat France <https://www.redhat.com>
BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92