-
Notifications
You must be signed in to change notification settings - Fork 734
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prevent compilation requests to be re-issued when code cache is exhausted #20448
Labels
Comments
Issue Number: 20448 |
mpirvu
added a commit
to mpirvu/openj9
that referenced
this issue
Nov 5, 2024
For large applications, the code caches can become full, preventing further JIT compilation. Compilation requests issued by the invocation counting mechanism of the interpreter will be rejected early by the JIT, before having the chance of being queued for compilation. Ideally, once a method has been rejected once, it will not be sent again for compilation. Currently this is not happening due to the circumstances described in eclipse-openj9#20448 This commit will prevent an interpreted method to be sent repeatedly for JIT compilation if compilation is disabled (because of code/data caches becoming full or because of a user specified command line option). Fixes: eclipse-openj9#20448 Signed-off-by: Marius Pirvu <[email protected]>
mpirvu
added a commit
to mpirvu/openj9
that referenced
this issue
Nov 5, 2024
For large applications, the code caches can become full, preventing further JIT compilation. Compilation requests issued by the invocation counting mechanism of the interpreter will be rejected early by the JIT, before having the chance of being queued for compilation. Ideally, once a method has been rejected once, it will not be sent again for compilation. Currently this is not happening due to the circumstances described in eclipse-openj9#20448 This commit will prevent an interpreted method to be sent repeatedly for JIT compilation if compilation is disabled (because of code/data caches becoming full or because of a user specified command line option). Fixes: eclipse-openj9#20448 Signed-off-by: Marius Pirvu <[email protected]>
Issue Number: 20448 |
zl-wang
pushed a commit
to zl-wang/openj9
that referenced
this issue
Nov 11, 2024
For large applications, the code caches can become full, preventing further JIT compilation. Compilation requests issued by the invocation counting mechanism of the interpreter will be rejected early by the JIT, before having the chance of being queued for compilation. Ideally, once a method has been rejected once, it will not be sent again for compilation. Currently this is not happening due to the circumstances described in eclipse-openj9#20448 This commit will prevent an interpreted method to be sent repeatedly for JIT compilation if compilation is disabled (because of code/data caches becoming full or because of a user specified command line option). Fixes: eclipse-openj9#20448 Signed-off-by: Marius Pirvu <[email protected]>
ThanHenderson
pushed a commit
to ThanHenderson/openj9
that referenced
this issue
Nov 25, 2024
For large applications, the code caches can become full, preventing further JIT compilation. Compilation requests issued by the invocation counting mechanism of the interpreter will be rejected early by the JIT, before having the chance of being queued for compilation. Ideally, once a method has been rejected once, it will not be sent again for compilation. Currently this is not happening due to the circumstances described in eclipse-openj9#20448 This commit will prevent an interpreted method to be sent repeatedly for JIT compilation if compilation is disabled (because of code/data caches becoming full or because of a user specified command line option). Fixes: eclipse-openj9#20448 Signed-off-by: Marius Pirvu <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When the code cache becomes full, the JIT uses
getCompilationInfo()->getPersistentInfo()->setDisableFurtherCompilation(true)
to prevent future compilation requests from being queued. The rejection happens in
Typically, once a method fails compilation, the JIT calls
compilationEnd()
which will calljitMethodFailedTranslation(vmThread, method)
, which writesJ9_JIT_NEVER_TRANSLATE
intoj9method->extra
so that the interpreter doesn't continue to send this method for compilation. The code looks like this:Note that calling
jitMethodFailedTranslation(vmThread, method);
is gated by a test onentry
. When a compilation is rejected early due to thegetPersistentInfo()->getDisableFurtherCompilation()
test, the entry does not exist because the compilation request has not yet been added to the compilation queue. Thus, j9method->extra is not set toJ9_JIT_NEVER_TRANSLATE
and the interpreter will send the method over and over again to the JIT compiler.This issue proposes to eliminate the test on
entry
incompilationEnd()
, provided it is safe to do so.The text was updated successfully, but these errors were encountered: