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

[David Holmes]

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