bpo-45947: Place dict and values pointer at fixed (negative) offset just before GC header. #29879
Conversation
…s and plain Python objects. Work in progress.
a76861c
to
79e61bf
Compare
|
If you want to schedule another build, you need to add the " |
|
If you want to schedule another build, you need to add the " |
| @@ -90,9 +90,6 @@ PyAPI_FUNC(int) PyObject_IS_GC(PyObject *obj); | |||
| # define _PyGC_FINALIZED(o) PyObject_GC_IsFinalized(o) | |||
| #endif | |||
|
|
|||
| PyAPI_FUNC(PyObject *) _PyObject_GC_Malloc(size_t size); | |||
There was a problem hiding this comment.
_PyObject_GC_Malloc is part of stable ABI. AFAIK the function cannot be removed.
There was a problem hiding this comment.
It's not part of the stable ABI. It starts with an underscore.
https://www.python.org/dev/peps/pep-0384/#excluded-functions
There was a problem hiding this comment.
Misc/stable_abi.txt define it as stable ABI.
function _PyObject_GC_Malloc
added 3.2
abi_only
On the other hand, no public macro in Python/C API use it. So I doubt it is actually stable abi.
As far as this repo, only one package in top4000 packages uses it.
https://github.com/hpyproject/top4000-pypi-packages/search?q=_PyObject_GC_Malloc
There was a problem hiding this comment.
I sent an email to python-dev asking for clarification of the status of this functions and others that start with _ but are listed in Misc/stable_abi.txt. (It is not listed in Doc/data/stable_abi.dat.)
| @@ -90,9 +90,6 @@ PyAPI_FUNC(int) PyObject_IS_GC(PyObject *obj); | |||
| # define _PyGC_FINALIZED(o) PyObject_GC_IsFinalized(o) | |||
| #endif | |||
|
|
|||
| PyAPI_FUNC(PyObject *) _PyObject_GC_Malloc(size_t size); | |||
There was a problem hiding this comment.
I sent an email to python-dev asking for clarification of the status of this functions and others that start with _ but are listed in Misc/stable_abi.txt. (It is not listed in Doc/data/stable_abi.dat.)
| _PyObject_GC_Link(PyObject *op) | ||
| { | ||
| PyGC_Head *g = AS_GC(op); | ||
| assert(((uintptr_t)g & (sizeof(uintptr_t)-1)) == 0); // g must be correctly aligned |
There was a problem hiding this comment.
Wow, you can use & on pointers. I didn't know that. :-)
There was a problem hiding this comment.
Only after you've cast it to an int. You can do anything with a cast
NULL is usually just 0 cast to a pointer, after all.
There was a problem hiding this comment.
Oh, somehow I thought uintptr_t was a pointer. :-/
Tools/gdb/libpython.py
Outdated
| Py_TPFLAGS_MANAGED_DICT = (1 << 4) | ||
| Py_TPFLAGS_HEAPTYPE = (1 << 9) |
There was a problem hiding this comment.
Please realign these like the rest?
| else { | ||
| if (!PyDict_CheckExact(dict)) { |
There was a problem hiding this comment.
I'm guessing that if we have a class of objects and only some of those have a materialized __dict__ that will wreak havoc with our specialization, right? Because it will flop-flop as it encounters instances with and without __dict__. In this case we have to hope that the vast majority don't have a __dict__.
There was a problem hiding this comment.
Yes.
The specialized case is so much faster though, that it might not be any worse than not specializing at all, even in that case.
Produces a solid 1% speedup
See faster-cpython/ideas#80 for full discussion.
https://bugs.python.org/issue45947