RFR: 8309271: A way to align already compiled methods with compiler directives

[Dmitry Chuyko]

Compiler Control (https://openjdk.org/jeps/165) provides method-context dependent control of the JVM compilers (C1 and C2). The active directive stack is built from the directive files passed with the `-XX:CompilerDirectivesFile` diagnostic command-line option and the Compiler.add_directives diagnostic command. It is also possible to clear all directives or remove the top from the stack.

A matching directive will be applied at method compilation time when such compilation is started. If directives are added or changed, but compilation does not start, then the state of compiled methods doesn't correspond to the rules. This is not an error, and it happens in long running applications when directives are added or removed after compilation of methods that could be matched. For example, the user decides that C2 compilation needs to be disabled for some method due to a compiler bug, issues such a directive but this does not affect the application behavior. In such case, the target application needs to be restarted, and such an operation can have high costs and risks. Another goal is testing/debugging compilers.

It would be convenient to optionally reconcile at least existing matching nmethods to the current stack of compiler directives. Methods in general are often inlined, and this information is hard to track down.

Natural way to eliminate the discrepancy between the result of compilation and the broken rule is to discard the compilation result, i.e. deoptimization. Obviously there is a performance penalty, so it should be applied with care. Hot code will most likely be recompiled soon, as nothing happens to its hotness.

A new flag '`-d`' has beed introduced for some directives related to compile commands: `Compiler.add_directives`, `Compiler.remove_directives`, `Compiler.clear_directives`. The default behavior has not changed (no flag). If the new flag is present, the command scans already compiled methods and marks for deoptimization those methods that have any active non-default matching compiler directives. There is currently no distinction which directives are found. In particular, this means that if there are rules for inlining into some method, it will be deoptimized. On the other hand, if there are rules for a method and it was inlined, top-level methods won't be deoptimized, but this can be achieved by having rules for them.

In addition, a new diagnistic command `Compiler.replace_directives`, has been added for convenience. It's like a combination of `Compiler.clear_directives` and `Compiler.add_directives`. It supports the same new optional '-d' flag that marks both cleared and added methods for deoptimization.

The behavior of the '-d' flag is implemented in the new `CodeCache::mark_for_deoptimization_directives_matches` and `DirectivesStack::hasMatchingDirectives` methods.

`CompilerDirectivesDCMDTest` now checks add, remove and replace commands in two modes (default and '-d') and checks that '-d' flag causes deoptimization.

An alternative approach to the '-d' flag could be to have a special diagnostic command for deoptimization. It will get a list of method patterns and reuse the matcher, however this is not so trivial. Overall usage and effects will be similar but this is one more file format. The user will also need to monitor or query active directives in advance, e.g. to deoptimize all mentioned methods after clearing all directives.

An alternative approach for selection of deoptimized methods could be to track down all inlining dependencies. This may be similar to searching references to old methods, but it requires scanning all code blobs, which looks too expensive.

An alternative naming for the flag is welcome. The obvious '-f' ('force') unfortunately has a conflict. Other verbs can be 'update', 'refresh' or 'apply'. Deoptimization is just what's done to reconcile the state. It could be something else, like first compiling with a different compiler and then switching to that version. Although in the latter case, triggered compilation would be an essential detail.

-------------

Commit messages:
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Formatting
 - Formatting
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Correct arguments info for new commands
 - Update through de-optimization

Changes: https://git.openjdk.org/jdk/pull/14111/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14111&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309271
  Stats: 214 lines in 9 files changed: 194 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/14111.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14111/head:pull/14111

PR: https://git.openjdk.org/jdk/pull/14111