This patch appropriately marks known false alarms in the
small object allocator when address sanity checking is
enabled (patch contributed by Dhiru Kholia).
The setobject freelist was consuming memory but not providing much value.
Even when a freelisted setobject was available, most of the setobject
fields still needed to be initialized and the small table still required
a memset(). This meant that the custom freelisting scheme for sets was
providing almost no incremental benefit over the default Python freelist
scheme used by _PyObject_Malloc() in Objects/obmalloc.c.
Issue #18942: sys._debugmallocstats() output was damaged on Windows.
_PyDebugAllocatorStats() called PyOS_snprintf() with a %zd format
code, but MS doesn't support that code. Interpolated
PY_FORMAT_SIZE_T in place of the "z".
_PyDebugAllocatorStats() called PyOS_snprintf() with a %zd format
code, but MS doesn't support that code. Interpolated
PY_FORMAT_SIZE_T in place of the "z".
Modern processors tend to make consecutive memory accesses cheaper than
random probes into memory.
Small sets can fit into L1 cache, so they get less benefit. But they do
come out ahead because the consecutive probes don't probe the same key
more than once and because the randomization step occurs less frequently
(or not at all).
For the open addressing step, putting the perturb shift before the index
calculation gets the upper bits into play sooner.
"Issue #18408: PyObject_Str(), PyObject_Repr() and type_call() now fail with an
assertion error if they are called with an exception set (PyErr_Occurred()).
As PyEval_EvalFrameEx(), they may clear the current exception and so the caller
looses its exception."
The Gdb prettyprint plugin depended on the dummy object being displayable.
Other solutions besides a unicode object are possible. For now, get it
back up and running.
The identity checks in lookkey() need to be there to prevent the dummy
object from leaking through Py_RichCompareBool() into user code in the
rare circumstance where the dummy's hash value exactly matches the hash
value of the actual key being looked up.
Remove an unused early-out test from the critical path for
dict and set lookups.
When the strings already have matching lengths, kinds, and hashes,
there is no additional information gained by checking the first
characters (the probability of a mismatch is already known to
be less than 1 in 2**64).
Letting the compiler decide how to optimize the multiply by five
gives it the freedom to make better choices for the best technique
for a given target machine.
For example, GCC on x86_64 produces a little bit better code:
Old-way (3 steps with a data dependency between each step):
shrq $5, %r13
leaq 1(%rbx,%r13), %rax
leaq (%rax,%rbx,4), %rbx
New-way (3 steps with no dependency between the first two steps
which can be run in parallel):
leaq (%rbx,%rbx,4), %rax # i*5
shrq $5, %r13 # perturb >>= PERTURB_SHIFT
leaq 1(%r13,%rax), %rbx # 1 + perturb + i*5
- replace 'long int' / 'long' by 'int'
- fix capitalization of "Python" in PyLong_AsUnsignedLong
- "is too large" -> "too large", for consistency with other messages.
PyStructSequence_InitType() except that it has a return value (0 on success,
-1 on error).
* PyStructSequence_InitType2() now raises MemoryError on memory allocation failure
* Fix also some calls to PyDict_SetItemString(): handle error
assertion error if they are called with an exception set (PyErr_Occurred()).
As PyEval_EvalFrameEx(), they may clear the current exception and so the caller
looses its exception.
_PyDict_GetItemId() is more efficient: it only builds the Unicode string once.
Identifiers (dictionary keys) are now created at Python initialization, and if
the creation failed, Python does exit with a fatal error.
Before, PyDict_GetItemString() failure was not handled: structseq_new() could
call PyObject_GC_NewVar() with a negative size, and structseq_dealloc() could
also crash.
It was easy to miss the call to type->tp_init because it was done in a long
conditional expression. Split the long expression in multiple lines to make the
debug step by step easier.
and _PyUnicode_HAS_WSTR_MEMORY() macros
These macros are called in unicode_dealloc(), whereas the unicode object can be
"inconsistent" if the creation of the object failed.
For example, when unicode_subtype_new() fails on a memory allocation,
_PyUnicode_CheckConsistency() fails with an assertion error because data is
NULL.
type->tp_str must not point to slot_tp_str() if type has no __str__ attribute,
so there is no reason for slot_tp_str() to fallback on slot_tp_str() on lookup
error. Moreover, calling PyErr_Clear() may hide a real bug like MemoryError.
If __str__ attribute is removed, slots must be updated (which is done by
type_setattro()).
Don't mark old extra memory dead before calling realloc(). realloc() can fail
and realloc() must not touch the original buffer on failure.
So mark old extra memory dead only on success if the new buffer did not move
(has the same address).