You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
compileOnSeparateThread()
{
...
if ((getNumCompThreadsActive() == 0
#if defined(J9VM_OPT_CRIU_SUPPORT)
|| getCRRuntime()->shouldSuspendThreadsForCheckpoint()
#endif
|| getPersistentInfo()->getDisableFurtherCompilation())
&& !details.isJitDumpMethod())
{
bool shouldReturn = true;
// Fail the compilation, unless this is on the queue (maybe even in progress)
if (!requestExistsInCompilationQueue(details, fe))
{
startPC = compilationEnd(vmThread, details, _jitConfig, 0, oldStartPC);
}
...
}
Typically, once a method fails compilation, the JIT calls compilationEnd() which will call jitMethodFailedTranslation(vmThread, method), which writes J9_JIT_NEVER_TRANSLATE into j9method->extra so that the interpreter doesn't continue to send this method for compilation. The code looks like this:
else if (!oldStartPC)
{
// Tell the VM that a non-compiled method failed translation
//
if (vmThread && entry && !entry->isOutOfProcessCompReq())
jitMethodFailedTranslation(vmThread, method);
Note that calling jitMethodFailedTranslation(vmThread, method); is gated by a test on entry. When a compilation is rejected early due to the getPersistentInfo()->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 to J9_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 in compilationEnd() , provided it is safe to do so.
The text was updated successfully, but these errors were encountered:
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 <mpirvu@ca.ibm.com>
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 <mpirvu@ca.ibm.com>
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: