GeezerVison

I believe this can be NOTRACE_DISPATCH() now, right? Likewise in FOR_ITER_RANGE

I honestly have a hunch that a bunch of the existing NOTRACE_DISPATCH() usage is incorrect and could trigger assertion failures (but haven't had time to look into it yet). I don't think NOTRACE_DISPATCH() is safe if we decref an untrusted value (like a list containing arbitrary elements) since the finalizer could start tracing. Right?

So in the range case it's safe, but probably not the list case (if my hunch is correct). What do you think?

I'm curious how much perf win we're getting from the NOTRACE_DISPATCH() stuff. It seems really tricky to get right, and it only saves one arithmetic operation on oparg.

I thought we were assuming that __del__ methods execute at an unspecified time, so if they turn on tracing, it shouldn't matter whether we actually start tracing a few instructions later.

I guess the unfortunate scenario would be where a __del__ method turns on tracing, then sees a few instructions traced, then returns to the Py_DECREF call site, and then can take a couple of instructions before it starts tracing that caller. I'm not sure whether that is acceptable.

Hm, well in that case we should at least remove all those assertions at the start of the quickened instructions. I also want to try benchmarking a branch were we just use DISPATCH() for everything, and see how much slower that is. If it's not much slower, it may just make sense to keep the tracing logic consistent for all instructions.

Want to make a new issue to review our use of NOTRACE_DISPATCH()?
I found a ~1% slowdown replacing all uses of it with DISPATCH().
If PEP 669 is accepted it will no longer be needed, as DISPATCH() will become the same as NOTRACE_DISPATCH()

#96636