JDK-8136552 : Last argument wins does not work for special options with "-XX:VMOptionsFile" option
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-09-15
  • Updated: 2015-11-12
  • Resolved: 2015-10-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b89Fixed
Related Reports
Relates :  
Description
If we have option file(name it "optionfile") with option which have special behavior("-XX:+PrintVMOptions") and ran java with following options:
./java -XX:VMOptionsFile=optionfile -XX:-PrintVMOptions -version

We expect that special PrintVMOption will be disabled since "last argument wins", because "-XX:-PrintVMOptions" is specified after VM Options file. But in current implementation we see:
java -XX:VMOptionsFile=optionfile -XX:-PrintVMOptions -version
VM option '+PrintVMOptions'
VM option '-PrintVMOptions'

That means that special option got value from VM Options file. This applied to the all special options("-XX:Flags", "-XX:+IgnoreUnrecognizedVMOptions" etc.). The problem is that in Arguments::match_special_option_and_act function "match specail option and act" mechanism is applied to the VM Options file only after all options from command line are compared with special options:
jint Arguments::match_special_option_and_act(const JavaVMInitArgs* args,
                                             char ** flags_file,
                                             char ** vm_options_file,
                                             ScopedVMInitArgs* vm_options_file_args,
                                             ScopedVMInitArgs* args_out) {
  // Remaining part of option string
  const char* tail;
  int   vm_options_file_pos = -1;

  for (int index = 0; index < args->nOptions; index++) {
    const JavaVMOption* option = args->options + index;
    if (ArgumentsExt::process_options(option)) {
      continue;
    }
    if (match_option(option, "-XX:Flags=", &tail)) {
      *flags_file = (char *) tail;
      if (*flags_file == NULL) {
        jio_fprintf(defaultStream::error_stream(),
                    "Cannot copy flags_file name.\n");
        return JNI_ENOMEM;
      }
      continue;
    }
    if (match_option(option, "-XX:VMOptionsFile=", &tail)) {
...
    }
    if (match_option(option, "-XX:+PrintVMOptions")) {
      PrintVMOptions = true;
      continue;
    }
...
  }

  // If there's a VMOptionsFile, parse that (also can set flags_file)
  if ((vm_options_file != NULL) && (*vm_options_file != NULL)) {
    return insert_vm_options_file(args, flags_file, vm_options_file,
                                  vm_options_file_pos, vm_options_file_args, args_out);
  }
  return JNI_OK;
} 
Comments
Dan's notes from a phone call with Ron about this bug: Dmitry's analysis above is spot on. The insert_vm_options_file() call is outside the main loop in match_special_option_and_act() so the current logic processes the input args (args), saves info about any VMOptionsFile option that was seen, processes remaining input args, and then processes the options in the VMOptionsFile. This violates the general left-to-right rule in HotSpot option processing. In Ron's original proposed fix for JDK-8061999, the VMOptionsFile was processed when it was encountered which preserved the general left-to-right rule. When the JDK-8061999 code was resynced with other fixes in the cmd line processing code, it was refactored into its current form and the processing of the VMOptionsFile was moved outside the loop. Unfortunately, we didn't have a test at the time that detected this breakage, but now we do. Thanks Dmitry! Ron, let me know if I transcribed what you were saying correctly.
06-10-2015