P4
From: https://mail.openjdk.org/pipermail/hotspot-dev/2025-November/115693.html
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.
---
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.
---
- links to
-
Commit(master)
openjdk/jdk/771253e2
-
Review(master)
openjdk/jdk/28579