IncreaseFirstTierCompileThresholdAt C1 option processed in explicit way, but it can be processed in general way. This will remove one "if" branch from very long "if-else if" statement in Arguments::parse_each_vm_init_arg function(hotspot/src/share/vm/runtime/arguments.cpp).

Description for IncreaseFirstTierCompileThresholdAt from hotspot/src/share/vm/runtime/globals.hpp: "Increase the compile threshold for C1 compilation if the code cache is filled by the specified percentage".

IncreaseFirstTierCompileThresholdAt processed explicit in Arguments::parse_each_vm_init_arg function(arguments.cpp module):
     } else if (match_option(option, "-XX:IncreaseFirstTierCompileThresholdAt=", &tail)) {
         uintx uint_IncreaseFirstTierCompileThresholdAt = 0;
         if (!parse_uintx(tail, &uint_IncreaseFirstTierCompileThresholdAt, 0) || uint_IncreaseFirstTierCompileThresholdAt > 99) {
           jio_fprintf(defaultStream::error_stream(),
                       "Invalid value for IncreaseFirstTierCompileThresholdAt: %s. Should be between 0 and 99.\n",
                       option->optionString);
           return JNI_EINVAL;
         }
         FLAG_SET_CMDLINE(uintx, IncreaseFirstTierCompileThresholdAt, (uintx)uint_IncreaseFirstTierCompileThresholdAt);


I don't see any reasons for explicit processing of this flag, except for upper range check. But I think that check for [0...99] interval can be moved to Arguments::check_vm_args_consistency function. Thus, I think will be great to remove explicit processing of this flag and add check for interval to Arguments::check_vm_args_consistency function.

I locally build JDK 9 with suggested fix and Java reports error for negative and above 99 values for IncreaseFirstTierCompileThresholdAt.