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

[Thomas Stüfe]

Yes, they should behave the same.

Cheers, Thomas

On Mon, Dec 1, 2025 at 10:41 AM Frederic Thevenet <fthevene at redhat.com>
wrote:

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