With uops always enabled, only test_embed fails, but that's the same on main (see GH-111339). I added that to benchmark Tier 2 perf (who knows, the speedier Tier switching may make things faster there).

@markshannon Can you review this? If you think this is roughly going in the right direction I will clean it up.

Whoops, back to draft, I accidentally left in the uops-forever cherrypick. Will fix later.

Alas, we still run out of stack space on the recursion tests on Windows. I'll keep working on this.

The tests run against debug builds, which will have very different stack usage patterns compared to optimised builds. I wouldn't worry too much about changing anything other than the default recursion limit (which is different for debug vs. release), and then do a buildbot run to check the optimised builds.

Otherwise, the best way to reduce stack usage will be to reduce the size of local variables, possibly by refactoring into separate functions so that the variables are only allocated temporarily and don't remain on the stack as the Python code recurses.

Otherwise, the best way to reduce stack usage will be to reduce the size of local variables, possibly by refactoring into separate functions so that the variables are only allocated temporarily and don't remain on the stack as the Python code recurses.

But the whole exercise is to merge two functions in one because we want to be able to transfer back and forth using goto rather than calls!

I will see by how much the debug recursion limit needs to be adjusted to make the tests pass; I think I have only two extra local variables left.

🤖 New build scheduled with the buildbot fleet by @gvanrossum for commit fdf1a2f 🤖

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

If this now passes the tests and the buildbots don't freak out I am going to merge this. However, @markshannon, could you have a look at how I fixed test_call? This feels like a band-aid.

Another fix would be to increase the value on this line:

That's what determines how much stack is available, and running out is what causes the hard crash. As you can see, it's already 4x larger for debug builds than releases, but it's still only 8MB and so making it larger isn't really going to hurt anyone much.

(I'll note that I haven't looked through the whole PR, so I don't know exactly what is causing it or whether the existing recursion limit comes into play at all. I'm just throwing out helpful pointers and trusting that you guys know what's actually going on :) )

Another fix would be to increase the value on this line:

Ah, thanks. That makes more sense. I don't know exactly what's going on either, but I know that I've added some local variables to the function containing the main interpreter loop, and that causes hard crashes in a bunch of tests that recurse deeply (at the C level). I'm now applying your fix instead of my previous hacks -- except I'm keeping the bit in test.support that dynamically pulls the value of Py_C_RECURSION_LIMIT1 from _testcapi (if it exists) rather than hardcoding a value that must be kept in sync with something defined in pystate.h. (It's technically still the case, but only if _testcapi can't be imported.)

I've just pushed that and if tests still pass I'll merge.