In the current nogil implementation, AFAICS, it seems the GIL can't be turned back on so there is no answer yet.
Theoretically, you could have a one-off operation which fixes all objects when the GIL is turned on. However, there's no way to get all objects in Python. gc.get_objects() only returns tracked objects, and there is no way to list untracked objects.
It seems, three fields are exposed on every CPython object in the stable ABI, any change which affects their offsets will break the stable ABI. https://github.com/capi-workgroup/problems/issues/4#issuecom...
> I'm not following why this affects ABI compatibility, sorry.
True, PyType_FromSpec can set tp_alloc to a wrapper function which papers over the difference in what the "allocfunc" should initialise the memory to.
Re performance - merging the change is the only way people will actually start targeting nogil.
Does that stay true once the GIL turns back on?
> These can override tp_alloc field to use custom memory allocators when instances of the type are instantiated. The custom memory allocator needs to initialise the reference count to 1.
I'm not following why this affects ABI compatibility, sorry.
> So there needs to be a branch at the start of list.append of whether to go to the old gil implementation or the new nogil one. Adding a branch so frequently will inherently make the runtime slower.
I don't know about that. CPUs handle always-taken and never-taken branches very well.