Loading... (original) (raw)

In this bug I'm talking about "regular" -XX options ("-XX:+Foo", "-XX:-Foo", "-XX:Foo=bar", etc) that have (or used to have) a matching variable in globals.hpp.

The "obsolete_jvm_flags" data structure was added to arguments.cpp to automatically deprecate or disable obsolete -XX options as the JDK version increases. But this doesn't handle other common kinds of options - in particular "alias" and "handled but deprecated" options.

A taxonomy of options:
Dead: Any use of the option results in an error***.
Obsolete & Deprecated: Any use of the option results in a warning, and the option setting is ignored.
Obsolete: Any use of the option is silently ignored.
Handled & Deprecated: Any use of the option results in a warning, and the option setting is used.
Handled: Regular, everyday option.
Aliased & Deprecated: Any use of the option results in a warning to use another option, and the other option is set to the value specified.
Aliased: Any use of the option sets the value of another option. No warning.

Currently the "obsolete_jvm_flags" handles the "Dead" and "Obsolete & Deprecated" cases, and normal argument processing covers "Handled".

We need a mechanism to handle "Aliased & Deprecated", and "Handled & Deprecated" options that will automatically transition an option to "Dead" in a specified JDK version. The mechanism should also support "Aliased" options. These two enhancements will remove a lot of custom option processing in Arguments::parse_each_vm_init_arg() and replace the need for check_deprecated_gc_flags().

This mechanism will enable the eventual removal of obsolete command line options that can otherwise linger in the code base for more than a decade. See for example bug 8061611 https://bugs.openjdk.java.net/browse/JDK-8061611