Since we request fresh pages of memory for JIT code, it's guaranteed to be zeroed anyways, so we can save space in the file and operations at runtime by eliding the writes where appropriate.

Note that even without that property, you could simply have issued a memset instead of copying from a statically-allocated area of zeros :)

Here's a before-and-after for one of our most common uops, _CHECK_VALIDITY:

It seems strange to have a dedicated µop doing just this :) Is there a documentation for µops somewhere?

It seems strange to have a dedicated µop doing just this :)

Does it? The role of this uop is to quickly check a single bit of state to check the our optimizer's assumptions hold. This can happen in lots of different places (a single Py_DECREF can change the world), so it helps to have a small check for it that can be put anywhere.

Is there a documentation for µops somewhere?

The general format and approach is documented in InternalDocs/jit.md. The individual uops aren't documented publicly, since they're a very unstable, low level implementation detail of an experimental feature. If there's a real need to internally document each of the 296 uops we currently have, we can probably find the time to do it. But most of them are either simple enough to follow (like type or dictionary version checks), or are identical to a full bytecode instruction that's already documented.

In the stripped version, code_body is still set to have the original length. Looks like the format string wasn't updated?

Yeah, that's expected. There are places where we use sizeof(code_body), and those are a bit more disruptive to change. I felt it wasn't worth it... the real wins come from saving space in the file, and removing entire memcpy calls.