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

[David Holmes]

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!

> 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?

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.

Cheers,
David
> Please note that in cases where unchanged flags are not printed out 
> (like in an hs_err report), no longer requiring  to unlock all flags to 
> print them out would have  no side effect, i.e. it would not increase 
> the amount of noise in the report (as in this case only modified flags 
> are printed out in, and for experimental flags this can only happen if 
> '+UnlockExperimentalVMOptions' is set to begin with).
> 
> Regards,
>