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

Frederic Thevenet fthevene at redhat.com
Wed Nov 26 14:53:51 UTC 2025


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).

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

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,

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