[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8309271: A way to align already compiled methods with compiler directives [v4]
From:       Dmitry Chuyko <dchuyko () openjdk ! org>
Date:       2023-07-25 22:09:04
Message-ID: m58yWIcCVHZtGpdLtiwdJcDWscc8DfWjbrbuc3G9wqI=.c3363b9e-d6d0-4fd1-ab68-fe867a461613 () github ! com
[Download RAW message or body]

> 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...

Dmitry Chuyko has updated the pull request incrementally with one additional commit \
since the last revision:

  jcheck fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14111/files
  - new: https://git.openjdk.org/jdk/pull/14111/files/40de84af..2d8cf4e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14111&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14111&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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


[prev in list] [next in list] [prev in thread] [next in thread]