Any reason why +PrintFlagsFinal requires unlocking experimental and diagnostic flags to print their default values?
Frederic Thevenet
fthevene at redhat.com
Mon Dec 1 10:10:25 UTC 2025
On 12/1/25 10:59, David Holmes wrote:
> On 1/12/2025 7:41 pm, Frederic Thevenet 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?
>
> I think that makes sense. Though you can then extend the same logic to
> PrintFlagsInitial and even PrintFlagsWithComments, so the scope
> expands. If you just want to restrict the change to PrintFlagsFinal
> then I think the simplest thing is to just expand:
>
> void JVMFlag::printFlags(outputStream* out, bool withComments, bool
> printRanges, bool skipDefaults) {
>
> to
>
> void JVMFlag::printFlags(outputStream* out, bool withComments, bool
> printRanges, bool skipDefaults, bool printLocked) {
>
> and then have
>
> // All the flags that get adjusted by VM_Version_init and os::init_2
> // have been set so dump the flags now.
> if (PrintFlagsFinal || PrintFlagsRanges) {
> JVMFlag::printFlags(tty, false, PrintFlagsRanges, false,
> PrintFlagsFinal);
> }
With regard to PrintFlagsInitial or PrintFlagsWithComments, it wasn't my
primary goal to change these but I can certainly look into it while I'm
at it if there is a consensus that it is in fact a good idea.
Anyone care to comment?
>
> David
>> 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
More information about the hotspot-dev
mailing list