On Wed, 24 May 2023 00:38:27 GMT, Dmitry Chuyko <dchu...@openjdk.org> wrote:
> 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 combinatio... "refresh" (-r) would be better than "deoptimize" (-d). The latter implies a specific implementation, the former is generic. If the method is to be recompiled, perhaps rather than deopt and wait, add it to the compile queue immediately and deopt the old version when the new compilation is complete, similar to what happens when the c1 version of the method is replaced by the c2 version. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14111#issuecomment-1583199824
