Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8066821

Enhance command line processing to manage deprecating and obsoleting -XX command line arguements

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Fixed
    • Icon: P4 P4
    • 9
    • 8
    • hotspot
    • b85

        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

              drwhite Derek White
              drwhite Derek White
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: