[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 [v19]
From:       Andrei Pangin <apangin () openjdk ! org>
Date:       2023-12-28 0:25:48
Message-ID: A2N70JPJsDcj9HDXDivLERq0raTYr13mEnxEFAyjH-A=.9b10f578-e013-4f59-8b61-28410bbad6bc () github ! com
[Download RAW message or body]

On Fri, 22 Dec 2023 09:33:06 GMT, Dmitry Chuyko <dchuyko@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 (so bypass inlined methods). \
> >  Natural way to eliminate the discrepancy between the result of compilation and \
> > the broken rule is to discard the compilation result, i.e. deoptimization. Prior \
> > to that we can try to re-compile the method letting compile broker to perform it \
> > taking new directives stack into account. Re-compilation helps to prevent hot \
> > methods from execution in the interpreter. 
> > A new flag `-r` 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 puts \
> > methods that have any active non-default matching compiler directives to \
> > re-compilation if possible, otherwise marks them for deoptimization. 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 refreshed. On \
> > the other hand, if there are rules for a method and it was inlined, top-level \
> > methods won't be refreshed, but this can be achieved by having rules for them. 
> > In addition, a new diagnostic command `Compiler.replace_directives...
> 
> Dmitry Chuyko has updated the pull request incrementally with one additional commit \
> since the last revision: 
> Deopt osr, cleanups

The logic looks good to me now, thanks.

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

Marked as reviewed by apangin (no project role).

PR Review: https://git.openjdk.org/jdk/pull/14111#pullrequestreview-1797576900


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