What "de-optimization events" should we track?

[markshannon]

Optimizers make speculative assumptions about the code they are optimizing. Although, some of these assumptions can be verified with inline checks, it is much more efficient for rare events to detect the de-optimization externally to the code and deliver a notification to the optimizer to de-optimize the code.

The two questions to answer are:

• What events do optimizers want to be notified about?
• How do we detect those events?

What events are worthy of notification?

Here's an incomplete list:

• Changes to select global variables.
• Changes to a function: changes to __code__, vectorcall, defaults, etc.
• Changes to a class (anything that would invalidate the version number).
• Changes to profiling or tracing: calls to sys.set_profile() or sys.set_trace()

Event detection

Many events can only only happen through a call to a C function.
Detection of those events is trivial: we detect them when that function is called.
E.g. Detecting when a function's __code__ attribute is modified is trivial: it happens when the func_set_code function is called.

Changes to global variables will be detected with dictionary watchers (python/cpython#91052)

What other events are of interest?

@undingen
@kmod
@carljm
@DinoV

[kmod]

"Changing a local variable via a frame object/proxy" comes to mind

[carljm]

Changes to a function: changes to __code__, vectorcall, defaults, etc.

FWIW we've also made a proposal for this at python/cpython#91053 and python/cpython#91054

Changes to a class

And for this at python/cpython#91051

At the moment I can't think of anything else that we've wanted? Cc also @mpage in case I missed anything.

We don't support changes to locals via a frame object and I'm not sure we care much about it, but if notification were easy and cheap we'd probably at least consider deopting for it.

We haven't yet bothered to implement deopt when a tracing/profiling function is set, but will probably do so at some point.