gh-94673: Add Per-Interpreter Storage for Static Builtin Types#94995
gh-94673: Add Per-Interpreter Storage for Static Builtin Types#94995ericsnowcurrently wants to merge 24 commits into
Conversation
|
For context, I have a branch on top of this one that takes care of tp_subclasses: main...ericsnowcurrently:shareable-static-types-tp_subclasses. |
|
Thanks for working on this! Mostly LGTM, a few changes worth looking into:
|
There should be no performance impact since it's still a single static offset from the pointer we were already dereferencing.
None of the other fields have a leading underscore, even the ones that are documented as internal. That does remind me, I should also add the new field to the docs. (Or maybe I'll ditch the new field and not worry about it. 🙂) |
| static int | ||
| slot_tp_setattro(PyObject *self, PyObject *name, PyObject *value); | ||
|
|
||
|
|
There was a problem hiding this comment.
|
The test_embed failure is because |
|
FYI, I tried printing some diagnostic info in minimal: This boils down to static type subclasses in extension modules, since they don't get finalized (ever). Maybe we should ignore static types in tp_subclasses... a more complex case
|
|
To solve the test_embed failure, I had to stop ignoring types in |
|
I'm going to split this PR up. |
This is a precursor to storing tp_subclasses (and tp_weaklist) on the interpreter state for static builtin types. At a high level, we add the following:
_PyStaticType_InitBuiltin()PyInterpreterState.types.builtinsWe also shuffle some code around to be able to use
_PyStaticType_InitBuiltin(), especially in Objects/structseq.c.One thing to note is that we add a new "tp_" field:
PyTypeObject.tp_static_builtin_index. If adding another field to PyTypeObject is too costly then we could conditionally re-purpose some other field (e.g.tp_subclassesonce we don't use it for static types).