Would it mean that "sum(range(10**9))" would create 10**9 immortal int objects? I see a risk of memory exhaustion, no?
Victor Le mer. 5 sept. 2018 à 13:14, Petr Viktorin encukou@gmail.com a écrit :
On 09/05/18 12:21, Victor Stinner wrote:
Le mer. 5 sept. 2018 à 09:17, Ronald Oussoren ronaldoussoren@mac.com a écrit :
In short:
- Leaking ob_field prevents to compile a C extension to the stable ABI
- Accessing directly ob_field prevents to change the structure and so experiment optimizations
- Accessing directly ob_field by derefering pointers expect that a pointer can be dereference which prevents to used tagged pointers
All of these are unrelated to borrowed references. Conceptually every instance owns a reference to its type, regardless of how and where that reference is stored, and it should be possible to return a borrowed reference.
You are describing the current ("old") C API. I ask you to imagine a new C API where PyObject* is really an opaque thing. It's better to even see as an integer (Py_uintptr_t) rather than a pointer.
I would like to use "PyObject*" as an opaque thing because I would like to be able to implement tagged pointer for example. If you store an integer inside a "PyObject*", there is no PyObject structure anywhere. There is no linked PyTypeObject anywhere.
But all existing C extensions really want a "PyObject*" which behaves as it's a real Python object with an associated PyObject structure linked to a concrete PyTypeObject. So in some places, we need to produce temporary PyLongObject which represent the integer stored in the tagged pointer.
Borrowed references are a blocker issue for that. How do you know when the temporary object should go away?
Tagged pointer is one example. Another example would be a list of integers which stores numbers are C integers (ex: int32_t) rather than PyLongObject. PyList_GetItemRef() has to create a temporary PyLongObject.
The tagged pointer optimization can only be used for a limited set of basic types int, bool, small str/bytes etc. Right? Can you make these basic type objects immortal? Their refcount would be ignored, their dealloc would be a no-op. If you need a heap type for some reason it would need to be destroyed specially at interpreter shutdown.