Hotspot defines 6 kinds of command-line flags (all starting with -XX):
These are the primary flags we intend end-users to apply for tuning, feature selection etc. These are settable via the command-line in product builds.
These are a special kind of product flag that can be dynamically set via the JDK management interface.
These are flags intended for use by Hotspot developers for debugging and testing purposes. These are settable only in non-product builds, and have a constant value in product builds.
A more constrained development flag that has no presence at all in a product build.
These flags are in support of features that are not part of the officially supported product, but are available in the product for experimenting with. They must be explicitly unlocked to be used. They are expected to be temporary in nature, and potentially replaced by a product flag in a later release if the feature remains. Experimental features can be dropped with no notice.
Diagnostic flags are not meant for VM tuning or for product modes. They are to be used for VM quality assurance or field diagnosis of VM bugs. They are hidden so that users will not be encouraged to try them as if they were product flags. However, they are available in the product version of the VM so they can be enabled under instruction to collect diagnostic information about VM problems.
The Hotspot team have a defined (up to) three step deprecation process for removing flags:
The full three step process is used for "product" and "manageable" flags. For the other flags we can start at step 2 and "obsolete" the flag in the current release.
The CSR Process
The Compatibility, Specification and Review (CSR) process ensures that all changes to exported interfaces are reviewed in depth to ensure they are well designed, and that compatibility concerns have been considered. These exported interfaces include the various flags and options that can be passed to the different command-line tools in the OpenJDK (java, javac, jlink, etc.)