Faster checks for recursion limit with better safety.

[markshannon]

There are two types of excessive recursions we want to prevent.

1. Run away recursion in Python, which is usually a bug.
2. Stack overflow which causes crashes and possible security vulnerabilities.

We can speed up the Python check by recording the remaining depth on the frame. This should have no impact on the speed of the entry check, but would eliminate the exit cleanup.
if (prev_frame->remaining_depth <= 0) { error() }; new_frame->remaining_depth = prev_frame->remaining_depth-1.

Stack overflow checks can be performed something like:
if (((uintptr_t)&local_var) - tstate->safe_region_base) >= SAFE_REGION_SIZE) { perform_update_or_raise(); }
Again, no exit cleanup is needed as we aren't modifying any state.

This approach more resilient to optimizations and compiler changes as we don't need to worry about balancing entries and exits.

Since PEP 651 was rejected we will probably need SC approval for this.

[iritkatriel]

We can speed up the Python check by recording the remaining depth on the frame.

I think this needs to take into account that the python code could change the limit during the recursion.

[markshannon]

We already use the remaining depth; we just recalculate it whenever the recursion limit is changed.

[pxeger]

Wouldn't that require sys.setrecursionlimit to go through and recalculate it for every frame - including suspended generator frames? How would those be accessed?

[markshannon]

Suspended generators aren't in the stack.

[gvanrossum]

I'm all for safer checks (C stack overflows are no fun to debug). Is the performance of if ++X >= Y) and X-- really an issue here though?

[markshannon]

It's not the arithmetic, it's the memory fetches that cost.