Make EntryPointInfo::callsCount usable by redeferral heuristic. #1757
Conversation
…e the uint8's toi uint32's, which in turn allows us to dispense with the full-JIT code that saturates these values at 255.
| Assert(simpleJitLimit == 0 ? callCount == 0 : simpleJitLimit > callCount); | ||
| return callCount == 0 ? | ||
| static_cast<uint16>(simpleJitLimit) : | ||
| static_cast<uint16>(simpleJitLimit) - callCount - 1; | ||
| static_cast<uint16>(simpleJitLimit) - static_cast<uint8>(callCount) - 1; |
There was a problem hiding this comment.
static_cast(callCount) [](start = 50, length = 29)
won't this give wrong values for callCount>255?
There was a problem hiding this comment.
The call count can't be > 255 while we're decrementing from the simple JIT limit toward zero. We could probably do without the static cast, but I didn't want any static tools complaining about overflow.
|
IIRC, the reason for saturating the call count at 255 was that if it were allowed to grow to uin32_max, and we started bailing out, it will take a long time for the call count to get to 0 and, in turn, for us to rejit the function. Is that not a concern anymore? |
|
I think @LouisLaf had an idea for mitigating this. Should be easy to add it later. |
|
|
||
| // bcs $overflow | ||
| Lowerer::InsertBranch(Js::OpCode::BrLt_A, true, overflowLabel, overflowLabel); | ||
|
|
There was a problem hiding this comment.
With int32, I think we don't even care about the overflow. Plus, with saturation, it doesn't fix the retiring problem, it just delays it.
| @@ -1763,7 +1763,7 @@ void BailOutRecord::ScheduleFunctionCodeGen(Js::ScriptFunction * function, Js::S | |||
| bailOutRecordNotConst->bailOutCount++; | |||
|
|
|||
| Js::FunctionEntryPointInfo *entryPointInfo = function->GetFunctionEntryPointInfo(); | |||
| uint8 callsCount = entryPointInfo->callsCount; | |||
| uint32 callsCount = entryPointInfo->callsCount; | |||
There was a problem hiding this comment.
You can just change this to:
uint32 callsCount = MIN(entryPointInfo->callsCount, 255);
to retain the previous bailout behavior we had with saturation.
| entryPointInfo->totalJittedLoopIterations = UINT8_MAX; | ||
| } | ||
| uint8 totalJittedLoopIterations = (uint8)entryPointInfo->totalJittedLoopIterations; | ||
| uint32 totalJittedLoopIterations = entryPointInfo->totalJittedLoopIterations; |
There was a problem hiding this comment.
uint32 totalJittedLoopIterations = entryPointInfo->totalJittedLoopIterations; [](start = 4, length = 77)
In keeping with @LouisLaf 's suggestion in ScheduleFunctionCodeGen, we should retain the existing code here.
Change the uint8's toi uint32's, which in turn allows us to dispense with the full-JIT code that saturates these values at 255.