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

[Thomas Stüfe]

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>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20251128/310c49c8/attachment.htm>