This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author nascheme
Recipients nascheme
Date 2019-06-07.19:32:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1559935936.79.0.824964365383.issue37200@roundup.psfhosted.org>
In-reply-to
Content
In the process of working on some garbage collector/obmalloc experiments, I noticed what seems to be a quirk about PyType_GenericAlloc().  It calls:

size = _PyObject_VAR_SIZE(type, nitems+1);

Note the "+1" which is documented as "for the sentinel".  That code dates back to change "e5c691abe3946ddbaa00730b92f3b96f96903f7d" when Guido added support for heap types.  This extra item is not added by _PyObject_GC_NewVar().  Also, the documentation for tp_alloc says that the size of the allocated block should be:

  tp_basicsize + nitems*tp_itemsize, rounded up to a multiple of sizeof(void*);

The "+1" for the sentinel is definitely needed in certain cases.  I think it might only be needed if 'type' is a subtype of 'type'.  I.e. if Py_TPFLAGS_TYPE_SUBCLASS is set on 'type'.

I haven't done enough analysis to fully understand this quirk yet but I think we are allocating extra memory quite regularly.  Quite a lot of types use tp_alloc = PyType_GenericAlloc.  E.g. the 'list' type or a subclass of the tuple type.

It seems with the attached patch, unit tests still pass.  Perhaps the +1 could be removed on the non-GC branch of the code as well.
History
Date User Action Args
2019-06-07 19:32:16naschemesetrecipients: + nascheme
2019-06-07 19:32:16naschemesetmessageid: <1559935936.79.0.824964365383.issue37200@roundup.psfhosted.org>
2019-06-07 19:32:16naschemelinkissue37200 messages
2019-06-07 19:32:16naschemecreate