GH-130396: Increase trashcan overhead

[markshannon]

• Issue: Implement stack overflow protection for linux based on actual stack depth #130396

[markshannon]

!buildbot Windows.*2022.*NoGIL

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @markshannon for commit 1a1a46c 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F130552%2Fmerge

The command will test the builders whose names match following regular expression: Windows.*2022.*NoGIL

The builders matched are:

• AMD64 Windows Server 2022 NoGIL PR

[markshannon]

!buildbot Windows.*2022.*NoGIL.*3

[bedevere-bot]

The regex 'Windows.*2022.*NoGIL.*3' did not match any buildbot builder. Is the requested builder in the list of stable builders?

[brandtbucher]

So, to make sure I understand:

• We used to deposit into the trashcan once we only had room for 1 interpreter entry. Now we start using it earlier, once we only have room for 2.
• We used to empty the trashcan if we had room for 2 interpreter entries, but now we only do it if we have room for 4.

Can you clarify why these new numbers are chosen? It seems like it made sense before: deposit if we don't have room for a finalizer (margin of 1), and don't empty if doing so would immediately start putting stuff back in the trashcan (margin of 2, one higher than what's used in Py_TRASHCAN_BEGIN).

Are the new numbers chosen just because they're "higher"? If so, it's probably PYOS_STACK_MARGIN that needs to be fixed, not this, since the accounting of the margins in these macros seems correct to me the way it currently is.

[markshannon]

It is possible that the increase in PYOS_STACK_MARGIN from #130554 will fix the failure.

Even so, I think it is a good idea to have a bit more headroom for the trashcan, so that raising exceptions, calls to instrumentation, sys.audit, etc don't trigger a recursion error.