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

[Frederic Thevenet]

Thanks for your comments, David.

On 11/27/25 03:05, David Holmes 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.
This make sense. What I note is that there hasn't been a strong reason 
against it either, that would have eluded me so far.

>> 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!
Right, I see your point. Even tough I originally didn't really see a 
case where doing so would be detrimental when looking at the current 
call sites for 'printFlags' where 'skipDefaults' is false, a blanket 
change on the established behaviour for this method would indeed be 
ill-advised.
>> 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.
Following my initial train of thoughts, my preference would go to 
changing the default behaviour for +PrintFlagsFinal, but adding a new 
flag would still be an improvement over the need to specify 
+UnlockDiagnosticVMOptions  and +UnlockExperimentalVMOptions.

> 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,
>>
>
Regards,

-- 
Frederic Thevenet
Senior Software Engineer - OpenJDK
Red Hat France <https://www.redhat.com>
BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92