Bug 815579: Increment usecount faster on MI to interpreter calls, r=dvander

This commit is contained in:
Hannes Verschore 2012-11-30 14:18:28 +01:00
parent c9ad72d0e5
commit dc68e67f03
2 changed files with 14 additions and 1 deletions

View File

@ -150,6 +150,13 @@ struct IonOptions
// stop running this function in IonMonkey. (default 512)
uint32 slowCallLimit;
// When caller runs in IM, but callee not, we take a slow path to the interpreter.
// This has a significant overhead. In order to decrease the number of times this happens,
// the useCount gets incremented faster to compile this function in IM and use the fastpath.
//
// Default: 5
uint32 slowCallIncUseCount;
void setEagerCompilation() {
eagerCompilation = true;
usesBeforeCompile = usesBeforeCompileNoJaeger = 0;
@ -183,7 +190,8 @@ struct IonOptions
inlineMaxTotalBytecodeLength(800),
inlineUseCountRatio(128),
eagerCompilation(false),
slowCallLimit(512)
slowCallLimit(512),
slowCallIncUseCount(5)
{
}
};

View File

@ -67,6 +67,11 @@ InvokeFunction(JSContext *cx, JSFunction *fun, uint32 argc, Value *argv, Value *
ForbidCompilation(cx, script);
}
}
// When caller runs in IM, but callee not, we take a slow path to the interpreter.
// This has a significant overhead. In order to decrease the number of times this happens,
// the useCount gets incremented faster to compile this function in IM and use the fastpath.
fun->nonLazyScript()->incUseCount(js_IonOptions.slowCallIncUseCount);
}
// TI will return false for monitorReturnTypes, meaning there is no