Hi Victor, Thank you for looking into these issues. They are very important to HPy too! HPy currently only supports head types for similar reasons to why they are important to sub-interpreters -- their lifecycle can be managed by the Python interpreter and they are not tied to the memory and life cycle of the dynamic library containing the C extension. E.g. with heap types the interpreter can control when a type is created and destroyed and when it can be accessed. We've run into some minor issues with the limitations in PyType_Slot (https://docs.python.org/3/c-api/type.html#c.PyType_Slot.PyType_Slot.slot) but we are working around them for the moment. It would be useful to have some sense of where PyType_FromSpec is headed -- e.g. is it a goal to have it support all of the features of static types in the future -- so that we can perhaps help suggest / implement small changes that head in the right direction and also ensure that HPy is aligned with the immediate future of the C API. Yours sincerely, Simon Cross

On 1/11/21 5:26 PM, Victor Stinner wrote:

Hi,

There are multiple PEPs covering heap types. The latest one refers to other PEPs: PEP 630 "Isolating Extension Modules" by Petr Viktorin. https://www.python.org/dev/peps/pep-0630/#motivation

The use case is to embed multiple Python instances (interpreters) in the same application process, or to embed Python with multiple calls to Py_Initialize/Py_Finalize (sequentially, not in parallel). Static types are causing different issues for these use cases.

If a type is immutable and has no references to heap-allocated objects, it could stay as a static type. The issue is that very many types don't fit that. For example, if some method needs to raise a module-specific exception, that's a reference to a heap-allocated type, because custom exceptions generally aren't static.

Also, it's not possible to destroy static types at Python exit, which goes against the on-going effort to destroy all Python objects at exit (bpo-1635741).

I don't see why we would need to destroy immutable static objects. They don't need to be freed.

On Tue, Jan 12, 2021 at 3:28 PM Petr Viktorin wrote:

If a type is immutable and has no references to heap-allocated objects, it could stay as a static type. The issue is that very many types don't fit that. For example, if some method needs to raise a module-specific exception, that's a reference to a heap-allocated type, because custom exceptions generally aren't static. (...) I don't see why we would need to destroy immutable static objects. They don't need to be freed.

I'm not sure of your definition of "immutable" here. At the C level, many immutable Python objects are mutable. For example, a str instance *can* be modified with the C level, and computing hash(<my string>) modifies the object as well (the internal cached hash value). Any type contains at least one Python object: the __mro__ tuple. Most types also contain a __subclass__ dictionary (by default, it's NULL). These objects are created at Python startup, but not destroyed at Python exit. See also tp_bases (tuple) and tp_dict (dict). I tried once to "finalize" static types, but it didn't go well: * https://github.com/python/cpython/pull/20763 * https://bugs.python.org/issue1635741#msg371119 It doesn't look to be safe to clear static types. Many functions rely on the fact that static types are "always there" and are never finalized. Also, only a few static types are cleared by my PR: many static types are left unchanged. For example, static types of the _io module. It seems like a safer approach is to continue the work on bpo-40077: "Convert static types to PyType_FromSpec()". Victor -- Night gathers, and now my watch begins. It shall not end until my death.

On 1/12/21 4:09 PM, Victor Stinner wrote:

On Tue, Jan 12, 2021 at 3:28 PM Petr Viktorin wrote:

...

If a type is immutable and has no references to heap-allocated objects, it could stay as a static type. The issue is that very many types don't fit that. For example, if some method needs to raise a module-specific exception, that's a reference to a heap-allocated type, because custom exceptions generally aren't static. (...) I don't see why we would need to destroy immutable static objects. They don't need to be freed.

I'm not sure of your definition of "immutable" here. At the C level, many immutable Python objects are mutable. For example, a str instance *can* be modified with the C level, and computing hash(<my string>) modifies the object as well (the internal cached hash value).

Any type contains at least one Python object: the __mro__ tuple. Most types also contain a __subclass__ dictionary (by default, it's NULL). These objects are created at Python startup, but not destroyed at Python exit. See also tp_bases (tuple) and tp_dict (dict).

Ah, right. __subclasses__ is the reason these need to be heap types (if they allow subclassing, which – isn't). If __mro__ is a tuple of static types, it could probably be made static as well; hashes could be protected by a lock.

I tried once to "finalize" static types, but it didn't go well:

* https://github.com/python/cpython/pull/20763 * https://bugs.python.org/issue1635741#msg371119

It doesn't look to be safe to clear static types. Many functions rely on the fact that static types are "always there" and are never finalized. Also, only a few static types are cleared by my PR: many static types are left unchanged. For example, static types of the _io module. It seems like a safer approach is to continue the work on bpo-40077: "Convert static types to PyType_FromSpec()".

Yes, seems so. And perhaps this has enough subtle details to want a PEP?

On 2021-01-12, Victor Stinner wrote:

It seems like a safer approach is to continue the work on bpo-40077: "Convert static types to PyType_FromSpec()".

I agree that trying to convert static types is a good idea. Another possible bonus might be that we can gain some performance by integrating garbage collection with the Python object memory allocator. Static types frustrate that effort. Could we have something easier to use than PyType_FromSpec(), for the purposes of coverting existing code? I was thinking of something like: static PyTypeObject Foo_TypeStatic = { } static PyTypeObject *Foo_Type; PyInit_foo(void) { Foo_Type = PyType_FromStatic(&Foo_TypeStatic); } The PyType_FromStatic() would return a new heap type, created by copying the static type. The static type could be marked as being unusable (e.g. with a type flag).

On 1/12/21 7:16 PM, Neil Schemenauer wrote:

On 2021-01-12, Victor Stinner wrote:

...

It seems like a safer approach is to continue the work on bpo-40077: "Convert static types to PyType_FromSpec()".

I agree that trying to convert static types is a good idea. Another possible bonus might be that we can gain some performance by integrating garbage collection with the Python object memory allocator. Static types frustrate that effort.

Could we have something easier to use than PyType_FromSpec(), for the purposes of coverting existing code? I was thinking of something like:

static PyTypeObject Foo_TypeStatic = { } static PyTypeObject *Foo_Type;

PyInit_foo(void) { Foo_Type = PyType_FromStatic(&Foo_TypeStatic); }

The PyType_FromStatic() would return a new heap type, created by copying the static type. The static type could be marked as being unusable (e.g. with a type flag).

Unfortunately, it's not just the creation that needs to be changed. You also need to decref Foo_Type somewhere. Your example is for "single-phase init" modules (pre-PEP 489). Those don't have a dealloc hook, so they will leak memory (e.g. in multiple Py_Initialize/Py_Finalize cycles). Multi-phase init (PEP 489) allows multiple module instances of extension modules. Assigning PyType_FromStatic's result to a static pointer would mean that every instance of the module will create a new type, and overwrite any existing one. And the deallocation will either leave a dangling pointer or NULL the pointer for other module instances. So, you need to make the type part of the module state, so that the module has proper ownership of the type. And that means you need to access the type from the module state any time you need to use it. At that point, IMO, PyType_FromStatic saves you so little work that it's not worth supporting a third variation of type creation code.

On 1/12/21 7:48 PM, Pablo Galindo Salgado wrote:

One worry that I have in general with this move is the usage of _PyType_GetModuleByDef to get the type object from the module definition. This normally involves getting a TLS in every instance creation,

Not TLS, it's walking the MRO.

which can impact notably performance for some perf-sensitive types or types that are created a lot.

But yes, that's right. _PyType_GetModuleByDef should not be used in perf-sensitive spots, at least not without profiling. There's often an alternative, though. Do you have any specific cases you're concerned about?

On Tue, 12 Jan 2021 at 18:21, Neil Schemenauer mailto:nas-python@arctrix.com> wrote:

On 2021-01-12, Victor Stinner wrote: > It seems like a safer approach is to continue the work on > bpo-40077: "Convert static types to PyType_FromSpec()".

I agree that trying to convert static types is a good idea.  Another possible bonus might be that we can gain some performance by integrating garbage collection with the Python object memory allocator.  Static types frustrate that effort.

Could we have something easier to use than PyType_FromSpec(), for the purposes of coverting existing code?  I was thinking of something like:

    static PyTypeObject Foo_TypeStatic = {     }     static PyTypeObject *Foo_Type;

    PyInit_foo(void)     {         Foo_Type = PyType_FromStatic(&Foo_TypeStatic);     }

The PyType_FromStatic() would return a new heap type, created by copying the static type.  The static type could be marked as being unusable (e.g. with a type flag). _______________________________________________ Python-Dev mailing list -- python-dev@python.org mailto:python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org mailto:python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/RPG2TRQL... https://mail.python.org/archives/list/python-dev@python.org/message/RPG2TRQL... Code of Conduct: http://python.org/psf/codeofconduct/ http://python.org/psf/codeofconduct/

_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HOCGUW3S... Code of Conduct: http://python.org/psf/codeofconduct/

On 2021-01-12, Pablo Galindo Salgado wrote:

One worry that I have in general with this move is the usage of _PyType_GetModuleByDef to get the type object from the module definition. This normally involves getting a TLS in every instance creation, which can impact notably performance for some perf-sensitive types or types that are created a lot.

I would say _PyType_GetModuleByDef is the problem. Why do we need to use such an ugly approach (walking the MRO) when Python defined classes don't have the same performance issue? E.g. class A: def b(): pass A.b.__globals__ IMHO, we should be working to make types and functions defined in extensions more like the pure Python versions. Related, my "__namespace__" idea[1] might be helpful in reducing the differences between pure Python modules and extension modules. Rather than functions having a __globals__ property, which is a dict, they would have a __namespace__, which is a module object. Basically, functions and methods known which global namespace (module) they have been defined in. For extension modules, when you call a function or method defined in the extension, it could be passed the module instance, by using the __namespace__ property. Maybe I'm missing some details on why this approach wouldn't work. However, at a high level, I don't see why it shouldn't. Maybe performance would be an issue? Reducing the number of branches in code paths like CALL_FUNCTION should help. 1. https://github.com/nascheme/cpython/tree/frame_no_builtins

On 1/12/21 8:23 PM, Neil Schemenauer wrote:

On 2021-01-12, Pablo Galindo Salgado wrote:

...

One worry that I have in general with this move is the usage of _PyType_GetModuleByDef to get the type object from the module definition. This normally involves getting a TLS in every instance creation, which can impact notably performance for some perf-sensitive types or types that are created a lot.

I would say _PyType_GetModuleByDef is the problem. Why do we need to use such an ugly approach (walking the MRO) when Python defined classes don't have the same performance issue? E.g.

class A: def b(): pass A.b.__globals__

IMHO, we should be working to make types and functions defined in extensions more like the pure Python versions.

Related, my "__namespace__" idea[1] might be helpful in reducing the differences between pure Python modules and extension modules. Rather than functions having a __globals__ property, which is a dict, they would have a __namespace__, which is a module object. Basically, functions and methods known which global namespace (module) they have been defined in. For extension modules, when you call a function or method defined in the extension, it could be passed the module instance, by using the __namespace__ property.

Maybe I'm missing some details on why this approach wouldn't work. However, at a high level, I don't see why it shouldn't. Maybe performance would be an issue? Reducing the number of branches in code paths like CALL_FUNCTION should help.

The main difference between Python and C functions is that in C, you need type safety. You can't store C state in a mutable dict (or module) accessible from Python, because when users invalidate your C invariants, you get a segfault rather than a nice AttributeError. Making methods "remember" their context does work though, and has already been implemented -- see PEP 573! It uses the *defining class* instead of __namespace__, but you can get the module from that quite easily. The only place it doesn't work are slot methods, which have a fixed C API. For example: PyObject *tp_repr(PyObject *self); int tp_init(PyObject *self, PyObject *args, PyObject *kwds); There is no good way to pass the method, module object, globals() or the defining class to such functions.

1. https://github.com/nascheme/cpython/tree/frame_no_builtins