1991-02-19 08:39:46 -04:00
|
|
|
/***********************************************************
|
2000-06-30 20:50:40 -03:00
|
|
|
Copyright (c) 2000, BeOpen.com.
|
|
|
|
Copyright (c) 1995-2000, Corporation for National Research Initiatives.
|
|
|
|
Copyright (c) 1990-1995, Stichting Mathematisch Centrum.
|
|
|
|
All rights reserved.
|
|
|
|
|
|
|
|
See the file "Misc/COPYRIGHT" for information on usage and
|
|
|
|
redistribution of this file, and for a DISCLAIMER OF ALL WARRANTIES.
|
1991-02-19 08:39:46 -04:00
|
|
|
******************************************************************/
|
|
|
|
|
1990-10-14 09:07:46 -03:00
|
|
|
/* Tuple object implementation */
|
|
|
|
|
1997-05-02 00:12:38 -03:00
|
|
|
#include "Python.h"
|
1990-10-14 09:07:46 -03:00
|
|
|
|
Patch by Charles G Waldman to avoid a sneaky memory leak in
_PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton
to limit the size of the free lists is also merged into this patch.
Charles wrote initially:
"""
Test Case: run the following code:
class Nothing:
def __len__(self):
return 5
def __getitem__(self, i):
if i < 3:
return i
else:
raise IndexError, i
def g(a,*b,**c):
return
for x in xrange(1000000):
g(*Nothing())
and watch Python's memory use go up and up.
Diagnosis:
The analysis begins with the call to PySequence_Tuple at line 1641 in
ceval.c - the argument to g is seen to be a sequence but not a tuple,
so it needs to be converted from an abstract sequence to a concrete
tuple. PySequence_Tuple starts off by creating a new tuple of length
5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements
were assigned, _PyTuple_Resize is called to make the 5-tuple into a
3-tuple. When we're all done the 3-tuple is decrefed, but rather than
being freed it is placed on the free_tuples cache.
The basic problem is that the 3-tuples are being added to the cache
but never picked up again, since _PyTuple_Resize doesn't make use of
the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and
there is already a 3-tuple in free_tuples[3], instead of using this
tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It
would more efficient to use the existing 3-tuple and cache the
5-tuple.
By making _PyTuple_Resize aware of the free_tuples (just as
PyTuple_New), we not only save a few calls to realloc, but also
prevent this misbehavior whereby tuples are being added to the
free_tuples list but never properly "recycled".
"""
And later:
"""
This patch replaces my submission of Sun, 16 Apr and addresses Jeremy
Hylton's suggestions that we also limit the size of the free tuple
list. I chose 2000 as the maximum number of tuples of any particular
size to save.
There was also a problem with the previous version of this patch
causing a core dump if Python was built with Py_TRACE_REFS. This is
fixed in the below version of the patch, which uses tupledealloc
instead of _Py_Dealloc.
"""
2000-04-21 18:15:05 -03:00
|
|
|
/* Speed optimization to avoid frequent malloc/free of small tuples */
|
1993-10-15 13:18:48 -03:00
|
|
|
#ifndef MAXSAVESIZE
|
Patch by Charles G Waldman to avoid a sneaky memory leak in
_PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton
to limit the size of the free lists is also merged into this patch.
Charles wrote initially:
"""
Test Case: run the following code:
class Nothing:
def __len__(self):
return 5
def __getitem__(self, i):
if i < 3:
return i
else:
raise IndexError, i
def g(a,*b,**c):
return
for x in xrange(1000000):
g(*Nothing())
and watch Python's memory use go up and up.
Diagnosis:
The analysis begins with the call to PySequence_Tuple at line 1641 in
ceval.c - the argument to g is seen to be a sequence but not a tuple,
so it needs to be converted from an abstract sequence to a concrete
tuple. PySequence_Tuple starts off by creating a new tuple of length
5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements
were assigned, _PyTuple_Resize is called to make the 5-tuple into a
3-tuple. When we're all done the 3-tuple is decrefed, but rather than
being freed it is placed on the free_tuples cache.
The basic problem is that the 3-tuples are being added to the cache
but never picked up again, since _PyTuple_Resize doesn't make use of
the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and
there is already a 3-tuple in free_tuples[3], instead of using this
tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It
would more efficient to use the existing 3-tuple and cache the
5-tuple.
By making _PyTuple_Resize aware of the free_tuples (just as
PyTuple_New), we not only save a few calls to realloc, but also
prevent this misbehavior whereby tuples are being added to the
free_tuples list but never properly "recycled".
"""
And later:
"""
This patch replaces my submission of Sun, 16 Apr and addresses Jeremy
Hylton's suggestions that we also limit the size of the free tuple
list. I chose 2000 as the maximum number of tuples of any particular
size to save.
There was also a problem with the previous version of this patch
causing a core dump if Python was built with Py_TRACE_REFS. This is
fixed in the below version of the patch, which uses tupledealloc
instead of _Py_Dealloc.
"""
2000-04-21 18:15:05 -03:00
|
|
|
#define MAXSAVESIZE 20 /* Largest tuple to save on free list */
|
|
|
|
#endif
|
|
|
|
#ifndef MAXSAVEDTUPLES
|
|
|
|
#define MAXSAVEDTUPLES 2000 /* Maximum number of tuples of each size to save */
|
1993-10-15 13:18:48 -03:00
|
|
|
#endif
|
|
|
|
|
|
|
|
#if MAXSAVESIZE > 0
|
Patch by Charles G Waldman to avoid a sneaky memory leak in
_PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton
to limit the size of the free lists is also merged into this patch.
Charles wrote initially:
"""
Test Case: run the following code:
class Nothing:
def __len__(self):
return 5
def __getitem__(self, i):
if i < 3:
return i
else:
raise IndexError, i
def g(a,*b,**c):
return
for x in xrange(1000000):
g(*Nothing())
and watch Python's memory use go up and up.
Diagnosis:
The analysis begins with the call to PySequence_Tuple at line 1641 in
ceval.c - the argument to g is seen to be a sequence but not a tuple,
so it needs to be converted from an abstract sequence to a concrete
tuple. PySequence_Tuple starts off by creating a new tuple of length
5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements
were assigned, _PyTuple_Resize is called to make the 5-tuple into a
3-tuple. When we're all done the 3-tuple is decrefed, but rather than
being freed it is placed on the free_tuples cache.
The basic problem is that the 3-tuples are being added to the cache
but never picked up again, since _PyTuple_Resize doesn't make use of
the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and
there is already a 3-tuple in free_tuples[3], instead of using this
tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It
would more efficient to use the existing 3-tuple and cache the
5-tuple.
By making _PyTuple_Resize aware of the free_tuples (just as
PyTuple_New), we not only save a few calls to realloc, but also
prevent this misbehavior whereby tuples are being added to the
free_tuples list but never properly "recycled".
"""
And later:
"""
This patch replaces my submission of Sun, 16 Apr and addresses Jeremy
Hylton's suggestions that we also limit the size of the free tuple
list. I chose 2000 as the maximum number of tuples of any particular
size to save.
There was also a problem with the previous version of this patch
causing a core dump if Python was built with Py_TRACE_REFS. This is
fixed in the below version of the patch, which uses tupledealloc
instead of _Py_Dealloc.
"""
2000-04-21 18:15:05 -03:00
|
|
|
/* Entries 1 up to MAXSAVESIZE are free lists, entry 0 is the empty
|
1993-10-15 13:18:48 -03:00
|
|
|
tuple () of which at most one instance will be allocated.
|
|
|
|
*/
|
1997-05-02 00:12:38 -03:00
|
|
|
static PyTupleObject *free_tuples[MAXSAVESIZE];
|
Patch by Charles G Waldman to avoid a sneaky memory leak in
_PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton
to limit the size of the free lists is also merged into this patch.
Charles wrote initially:
"""
Test Case: run the following code:
class Nothing:
def __len__(self):
return 5
def __getitem__(self, i):
if i < 3:
return i
else:
raise IndexError, i
def g(a,*b,**c):
return
for x in xrange(1000000):
g(*Nothing())
and watch Python's memory use go up and up.
Diagnosis:
The analysis begins with the call to PySequence_Tuple at line 1641 in
ceval.c - the argument to g is seen to be a sequence but not a tuple,
so it needs to be converted from an abstract sequence to a concrete
tuple. PySequence_Tuple starts off by creating a new tuple of length
5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements
were assigned, _PyTuple_Resize is called to make the 5-tuple into a
3-tuple. When we're all done the 3-tuple is decrefed, but rather than
being freed it is placed on the free_tuples cache.
The basic problem is that the 3-tuples are being added to the cache
but never picked up again, since _PyTuple_Resize doesn't make use of
the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and
there is already a 3-tuple in free_tuples[3], instead of using this
tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It
would more efficient to use the existing 3-tuple and cache the
5-tuple.
By making _PyTuple_Resize aware of the free_tuples (just as
PyTuple_New), we not only save a few calls to realloc, but also
prevent this misbehavior whereby tuples are being added to the
free_tuples list but never properly "recycled".
"""
And later:
"""
This patch replaces my submission of Sun, 16 Apr and addresses Jeremy
Hylton's suggestions that we also limit the size of the free tuple
list. I chose 2000 as the maximum number of tuples of any particular
size to save.
There was also a problem with the previous version of this patch
causing a core dump if Python was built with Py_TRACE_REFS. This is
fixed in the below version of the patch, which uses tupledealloc
instead of _Py_Dealloc.
"""
2000-04-21 18:15:05 -03:00
|
|
|
static int num_free_tuples[MAXSAVESIZE];
|
1993-10-15 13:18:48 -03:00
|
|
|
#endif
|
|
|
|
#ifdef COUNT_ALLOCS
|
|
|
|
int fast_tuple_allocs;
|
|
|
|
int tuple_zero_allocs;
|
|
|
|
#endif
|
|
|
|
|
1997-05-02 00:12:38 -03:00
|
|
|
PyObject *
|
|
|
|
PyTuple_New(size)
|
1990-10-14 09:07:46 -03:00
|
|
|
register int size;
|
|
|
|
{
|
|
|
|
register int i;
|
1997-05-02 00:12:38 -03:00
|
|
|
register PyTupleObject *op;
|
1990-10-14 09:07:46 -03:00
|
|
|
if (size < 0) {
|
1997-05-02 00:12:38 -03:00
|
|
|
PyErr_BadInternalCall();
|
1990-10-14 09:07:46 -03:00
|
|
|
return NULL;
|
|
|
|
}
|
1993-10-15 13:18:48 -03:00
|
|
|
#if MAXSAVESIZE > 0
|
1993-11-01 09:46:50 -04:00
|
|
|
if (size == 0 && free_tuples[0]) {
|
|
|
|
op = free_tuples[0];
|
1997-05-02 00:12:38 -03:00
|
|
|
Py_INCREF(op);
|
1993-10-15 13:18:48 -03:00
|
|
|
#ifdef COUNT_ALLOCS
|
|
|
|
tuple_zero_allocs++;
|
|
|
|
#endif
|
1997-05-02 00:12:38 -03:00
|
|
|
return (PyObject *) op;
|
1993-10-15 13:18:48 -03:00
|
|
|
}
|
1997-05-02 00:12:38 -03:00
|
|
|
if (0 < size && size < MAXSAVESIZE &&
|
|
|
|
(op = free_tuples[size]) != NULL)
|
|
|
|
{
|
|
|
|
free_tuples[size] = (PyTupleObject *) op->ob_item[0];
|
Patch by Charles G Waldman to avoid a sneaky memory leak in
_PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton
to limit the size of the free lists is also merged into this patch.
Charles wrote initially:
"""
Test Case: run the following code:
class Nothing:
def __len__(self):
return 5
def __getitem__(self, i):
if i < 3:
return i
else:
raise IndexError, i
def g(a,*b,**c):
return
for x in xrange(1000000):
g(*Nothing())
and watch Python's memory use go up and up.
Diagnosis:
The analysis begins with the call to PySequence_Tuple at line 1641 in
ceval.c - the argument to g is seen to be a sequence but not a tuple,
so it needs to be converted from an abstract sequence to a concrete
tuple. PySequence_Tuple starts off by creating a new tuple of length
5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements
were assigned, _PyTuple_Resize is called to make the 5-tuple into a
3-tuple. When we're all done the 3-tuple is decrefed, but rather than
being freed it is placed on the free_tuples cache.
The basic problem is that the 3-tuples are being added to the cache
but never picked up again, since _PyTuple_Resize doesn't make use of
the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and
there is already a 3-tuple in free_tuples[3], instead of using this
tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It
would more efficient to use the existing 3-tuple and cache the
5-tuple.
By making _PyTuple_Resize aware of the free_tuples (just as
PyTuple_New), we not only save a few calls to realloc, but also
prevent this misbehavior whereby tuples are being added to the
free_tuples list but never properly "recycled".
"""
And later:
"""
This patch replaces my submission of Sun, 16 Apr and addresses Jeremy
Hylton's suggestions that we also limit the size of the free tuple
list. I chose 2000 as the maximum number of tuples of any particular
size to save.
There was also a problem with the previous version of this patch
causing a core dump if Python was built with Py_TRACE_REFS. This is
fixed in the below version of the patch, which uses tupledealloc
instead of _Py_Dealloc.
"""
2000-04-21 18:15:05 -03:00
|
|
|
num_free_tuples[size]--;
|
1993-10-15 13:18:48 -03:00
|
|
|
#ifdef COUNT_ALLOCS
|
|
|
|
fast_tuple_allocs++;
|
1998-12-11 10:56:38 -04:00
|
|
|
#endif
|
2000-05-03 20:44:39 -03:00
|
|
|
/* PyObject_InitVar is inlined */
|
1998-12-11 10:56:38 -04:00
|
|
|
#ifdef Py_TRACE_REFS
|
|
|
|
op->ob_size = size;
|
2000-05-03 20:44:39 -03:00
|
|
|
op->ob_type = &PyTuple_Type;
|
1993-10-15 13:18:48 -03:00
|
|
|
#endif
|
2000-05-03 20:44:39 -03:00
|
|
|
_Py_NewReference((PyObject *)op);
|
1997-08-04 23:16:08 -03:00
|
|
|
}
|
|
|
|
else
|
1993-10-15 13:18:48 -03:00
|
|
|
#endif
|
|
|
|
{
|
1999-07-12 20:06:58 -03:00
|
|
|
int nbytes = size * sizeof(PyObject *);
|
|
|
|
/* Check for overflow */
|
|
|
|
if (nbytes / sizeof(PyObject *) != (size_t)size ||
|
2000-06-23 16:37:02 -03:00
|
|
|
(nbytes += sizeof(PyTupleObject) - sizeof(PyObject *)
|
2000-06-30 02:02:53 -03:00
|
|
|
+ PyGC_HEAD_SIZE)
|
1999-07-12 20:06:58 -03:00
|
|
|
<= 0)
|
|
|
|
{
|
|
|
|
return PyErr_NoMemory();
|
|
|
|
}
|
2000-05-03 20:44:39 -03:00
|
|
|
/* PyObject_NewVar is inlined */
|
|
|
|
op = (PyTupleObject *) PyObject_MALLOC(nbytes);
|
1993-10-15 13:18:48 -03:00
|
|
|
if (op == NULL)
|
1997-05-02 00:12:38 -03:00
|
|
|
return PyErr_NoMemory();
|
2000-06-30 02:02:53 -03:00
|
|
|
op = (PyTupleObject *) PyObject_FROM_GC(op);
|
2000-05-03 20:44:39 -03:00
|
|
|
PyObject_INIT_VAR(op, &PyTuple_Type, size);
|
1993-10-15 13:18:48 -03:00
|
|
|
}
|
1990-10-14 09:07:46 -03:00
|
|
|
for (i = 0; i < size; i++)
|
|
|
|
op->ob_item[i] = NULL;
|
1993-10-15 13:18:48 -03:00
|
|
|
#if MAXSAVESIZE > 0
|
|
|
|
if (size == 0) {
|
1993-11-01 09:46:50 -04:00
|
|
|
free_tuples[0] = op;
|
Patch by Charles G Waldman to avoid a sneaky memory leak in
_PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton
to limit the size of the free lists is also merged into this patch.
Charles wrote initially:
"""
Test Case: run the following code:
class Nothing:
def __len__(self):
return 5
def __getitem__(self, i):
if i < 3:
return i
else:
raise IndexError, i
def g(a,*b,**c):
return
for x in xrange(1000000):
g(*Nothing())
and watch Python's memory use go up and up.
Diagnosis:
The analysis begins with the call to PySequence_Tuple at line 1641 in
ceval.c - the argument to g is seen to be a sequence but not a tuple,
so it needs to be converted from an abstract sequence to a concrete
tuple. PySequence_Tuple starts off by creating a new tuple of length
5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements
were assigned, _PyTuple_Resize is called to make the 5-tuple into a
3-tuple. When we're all done the 3-tuple is decrefed, but rather than
being freed it is placed on the free_tuples cache.
The basic problem is that the 3-tuples are being added to the cache
but never picked up again, since _PyTuple_Resize doesn't make use of
the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and
there is already a 3-tuple in free_tuples[3], instead of using this
tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It
would more efficient to use the existing 3-tuple and cache the
5-tuple.
By making _PyTuple_Resize aware of the free_tuples (just as
PyTuple_New), we not only save a few calls to realloc, but also
prevent this misbehavior whereby tuples are being added to the
free_tuples list but never properly "recycled".
"""
And later:
"""
This patch replaces my submission of Sun, 16 Apr and addresses Jeremy
Hylton's suggestions that we also limit the size of the free tuple
list. I chose 2000 as the maximum number of tuples of any particular
size to save.
There was also a problem with the previous version of this patch
causing a core dump if Python was built with Py_TRACE_REFS. This is
fixed in the below version of the patch, which uses tupledealloc
instead of _Py_Dealloc.
"""
2000-04-21 18:15:05 -03:00
|
|
|
++num_free_tuples[0];
|
1997-05-02 00:12:38 -03:00
|
|
|
Py_INCREF(op); /* extra INCREF so that this is never freed */
|
1993-10-15 13:18:48 -03:00
|
|
|
}
|
|
|
|
#endif
|
2000-06-30 02:02:53 -03:00
|
|
|
PyObject_GC_Init(op);
|
1997-05-02 00:12:38 -03:00
|
|
|
return (PyObject *) op;
|
1990-10-14 09:07:46 -03:00
|
|
|
}
|
|
|
|
|
|
|
|
int
|
1997-05-02 00:12:38 -03:00
|
|
|
PyTuple_Size(op)
|
|
|
|
register PyObject *op;
|
1990-10-14 09:07:46 -03:00
|
|
|
{
|
1997-05-02 00:12:38 -03:00
|
|
|
if (!PyTuple_Check(op)) {
|
|
|
|
PyErr_BadInternalCall();
|
1990-10-14 09:07:46 -03:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
else
|
1997-05-02 00:12:38 -03:00
|
|
|
return ((PyTupleObject *)op)->ob_size;
|
1990-10-14 09:07:46 -03:00
|
|
|
}
|
|
|
|
|
1997-05-02 00:12:38 -03:00
|
|
|
PyObject *
|
|
|
|
PyTuple_GetItem(op, i)
|
|
|
|
register PyObject *op;
|
1990-10-14 09:07:46 -03:00
|
|
|
register int i;
|
|
|
|
{
|
1997-05-02 00:12:38 -03:00
|
|
|
if (!PyTuple_Check(op)) {
|
|
|
|
PyErr_BadInternalCall();
|
1990-10-14 09:07:46 -03:00
|
|
|
return NULL;
|
|
|
|
}
|
1997-05-02 00:12:38 -03:00
|
|
|
if (i < 0 || i >= ((PyTupleObject *)op) -> ob_size) {
|
|
|
|
PyErr_SetString(PyExc_IndexError, "tuple index out of range");
|
1990-10-14 09:07:46 -03:00
|
|
|
return NULL;
|
|
|
|
}
|
1997-05-02 00:12:38 -03:00
|
|
|
return ((PyTupleObject *)op) -> ob_item[i];
|
1990-10-14 09:07:46 -03:00
|
|
|
}
|
|
|
|
|
|
|
|
int
|
1997-05-02 00:12:38 -03:00
|
|
|
PyTuple_SetItem(op, i, newitem)
|
|
|
|
register PyObject *op;
|
1990-10-14 09:07:46 -03:00
|
|
|
register int i;
|
1997-05-02 00:12:38 -03:00
|
|
|
PyObject *newitem;
|
1990-10-14 09:07:46 -03:00
|
|
|
{
|
1997-05-02 00:12:38 -03:00
|
|
|
register PyObject *olditem;
|
|
|
|
register PyObject **p;
|
1997-08-17 13:25:45 -03:00
|
|
|
if (!PyTuple_Check(op) || op->ob_refcnt != 1) {
|
1997-05-02 00:12:38 -03:00
|
|
|
Py_XDECREF(newitem);
|
|
|
|
PyErr_BadInternalCall();
|
1990-10-21 19:15:08 -03:00
|
|
|
return -1;
|
1990-10-14 09:07:46 -03:00
|
|
|
}
|
1997-05-02 00:12:38 -03:00
|
|
|
if (i < 0 || i >= ((PyTupleObject *)op) -> ob_size) {
|
|
|
|
Py_XDECREF(newitem);
|
|
|
|
PyErr_SetString(PyExc_IndexError,
|
|
|
|
"tuple assignment index out of range");
|
1990-10-21 19:15:08 -03:00
|
|
|
return -1;
|
1990-10-14 09:07:46 -03:00
|
|
|
}
|
1997-05-02 00:12:38 -03:00
|
|
|
p = ((PyTupleObject *)op) -> ob_item + i;
|
1995-03-09 08:12:50 -04:00
|
|
|
olditem = *p;
|
|
|
|
*p = newitem;
|
1997-05-02 00:12:38 -03:00
|
|
|
Py_XDECREF(olditem);
|
1990-10-14 09:07:46 -03:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Methods */
|
|
|
|
|
|
|
|
static void
|
|
|
|
tupledealloc(op)
|
1997-05-02 00:12:38 -03:00
|
|
|
register PyTupleObject *op;
|
1990-10-14 09:07:46 -03:00
|
|
|
{
|
|
|
|
register int i;
|
Patch by Charles G Waldman to avoid a sneaky memory leak in
_PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton
to limit the size of the free lists is also merged into this patch.
Charles wrote initially:
"""
Test Case: run the following code:
class Nothing:
def __len__(self):
return 5
def __getitem__(self, i):
if i < 3:
return i
else:
raise IndexError, i
def g(a,*b,**c):
return
for x in xrange(1000000):
g(*Nothing())
and watch Python's memory use go up and up.
Diagnosis:
The analysis begins with the call to PySequence_Tuple at line 1641 in
ceval.c - the argument to g is seen to be a sequence but not a tuple,
so it needs to be converted from an abstract sequence to a concrete
tuple. PySequence_Tuple starts off by creating a new tuple of length
5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements
were assigned, _PyTuple_Resize is called to make the 5-tuple into a
3-tuple. When we're all done the 3-tuple is decrefed, but rather than
being freed it is placed on the free_tuples cache.
The basic problem is that the 3-tuples are being added to the cache
but never picked up again, since _PyTuple_Resize doesn't make use of
the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and
there is already a 3-tuple in free_tuples[3], instead of using this
tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It
would more efficient to use the existing 3-tuple and cache the
5-tuple.
By making _PyTuple_Resize aware of the free_tuples (just as
PyTuple_New), we not only save a few calls to realloc, but also
prevent this misbehavior whereby tuples are being added to the
free_tuples list but never properly "recycled".
"""
And later:
"""
This patch replaces my submission of Sun, 16 Apr and addresses Jeremy
Hylton's suggestions that we also limit the size of the free tuple
list. I chose 2000 as the maximum number of tuples of any particular
size to save.
There was also a problem with the previous version of this patch
causing a core dump if Python was built with Py_TRACE_REFS. This is
fixed in the below version of the patch, which uses tupledealloc
instead of _Py_Dealloc.
"""
2000-04-21 18:15:05 -03:00
|
|
|
register int len = op->ob_size;
|
2000-03-13 12:01:29 -04:00
|
|
|
Py_TRASHCAN_SAFE_BEGIN(op)
|
2000-06-30 02:02:53 -03:00
|
|
|
PyObject_GC_Fini(op);
|
Patch by Charles G Waldman to avoid a sneaky memory leak in
_PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton
to limit the size of the free lists is also merged into this patch.
Charles wrote initially:
"""
Test Case: run the following code:
class Nothing:
def __len__(self):
return 5
def __getitem__(self, i):
if i < 3:
return i
else:
raise IndexError, i
def g(a,*b,**c):
return
for x in xrange(1000000):
g(*Nothing())
and watch Python's memory use go up and up.
Diagnosis:
The analysis begins with the call to PySequence_Tuple at line 1641 in
ceval.c - the argument to g is seen to be a sequence but not a tuple,
so it needs to be converted from an abstract sequence to a concrete
tuple. PySequence_Tuple starts off by creating a new tuple of length
5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements
were assigned, _PyTuple_Resize is called to make the 5-tuple into a
3-tuple. When we're all done the 3-tuple is decrefed, but rather than
being freed it is placed on the free_tuples cache.
The basic problem is that the 3-tuples are being added to the cache
but never picked up again, since _PyTuple_Resize doesn't make use of
the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and
there is already a 3-tuple in free_tuples[3], instead of using this
tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It
would more efficient to use the existing 3-tuple and cache the
5-tuple.
By making _PyTuple_Resize aware of the free_tuples (just as
PyTuple_New), we not only save a few calls to realloc, but also
prevent this misbehavior whereby tuples are being added to the
free_tuples list but never properly "recycled".
"""
And later:
"""
This patch replaces my submission of Sun, 16 Apr and addresses Jeremy
Hylton's suggestions that we also limit the size of the free tuple
list. I chose 2000 as the maximum number of tuples of any particular
size to save.
There was also a problem with the previous version of this patch
causing a core dump if Python was built with Py_TRACE_REFS. This is
fixed in the below version of the patch, which uses tupledealloc
instead of _Py_Dealloc.
"""
2000-04-21 18:15:05 -03:00
|
|
|
if (len > 0) {
|
|
|
|
i = len;
|
1998-06-26 12:53:50 -03:00
|
|
|
while (--i >= 0)
|
|
|
|
Py_XDECREF(op->ob_item[i]);
|
1993-10-15 13:18:48 -03:00
|
|
|
#if MAXSAVESIZE > 0
|
Patch by Charles G Waldman to avoid a sneaky memory leak in
_PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton
to limit the size of the free lists is also merged into this patch.
Charles wrote initially:
"""
Test Case: run the following code:
class Nothing:
def __len__(self):
return 5
def __getitem__(self, i):
if i < 3:
return i
else:
raise IndexError, i
def g(a,*b,**c):
return
for x in xrange(1000000):
g(*Nothing())
and watch Python's memory use go up and up.
Diagnosis:
The analysis begins with the call to PySequence_Tuple at line 1641 in
ceval.c - the argument to g is seen to be a sequence but not a tuple,
so it needs to be converted from an abstract sequence to a concrete
tuple. PySequence_Tuple starts off by creating a new tuple of length
5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements
were assigned, _PyTuple_Resize is called to make the 5-tuple into a
3-tuple. When we're all done the 3-tuple is decrefed, but rather than
being freed it is placed on the free_tuples cache.
The basic problem is that the 3-tuples are being added to the cache
but never picked up again, since _PyTuple_Resize doesn't make use of
the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and
there is already a 3-tuple in free_tuples[3], instead of using this
tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It
would more efficient to use the existing 3-tuple and cache the
5-tuple.
By making _PyTuple_Resize aware of the free_tuples (just as
PyTuple_New), we not only save a few calls to realloc, but also
prevent this misbehavior whereby tuples are being added to the
free_tuples list but never properly "recycled".
"""
And later:
"""
This patch replaces my submission of Sun, 16 Apr and addresses Jeremy
Hylton's suggestions that we also limit the size of the free tuple
list. I chose 2000 as the maximum number of tuples of any particular
size to save.
There was also a problem with the previous version of this patch
causing a core dump if Python was built with Py_TRACE_REFS. This is
fixed in the below version of the patch, which uses tupledealloc
instead of _Py_Dealloc.
"""
2000-04-21 18:15:05 -03:00
|
|
|
if (len < MAXSAVESIZE && num_free_tuples[len] < MAXSAVEDTUPLES) {
|
|
|
|
op->ob_item[0] = (PyObject *) free_tuples[len];
|
|
|
|
num_free_tuples[len]++;
|
|
|
|
free_tuples[len] = op;
|
2000-03-13 12:01:29 -04:00
|
|
|
goto done; /* return */
|
1998-06-26 12:53:50 -03:00
|
|
|
}
|
1993-10-15 13:18:48 -03:00
|
|
|
#endif
|
1998-06-26 12:53:50 -03:00
|
|
|
}
|
2000-05-03 20:44:39 -03:00
|
|
|
PyObject_DEL(op);
|
2000-03-13 12:01:29 -04:00
|
|
|
done:
|
|
|
|
Py_TRASHCAN_SAFE_END(op)
|
1990-10-14 09:07:46 -03:00
|
|
|
}
|
|
|
|
|
1991-06-07 19:59:30 -03:00
|
|
|
static int
|
1990-10-14 09:07:46 -03:00
|
|
|
tupleprint(op, fp, flags)
|
1997-05-02 00:12:38 -03:00
|
|
|
PyTupleObject *op;
|
1990-10-14 09:07:46 -03:00
|
|
|
FILE *fp;
|
|
|
|
int flags;
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
fprintf(fp, "(");
|
1991-06-07 19:59:30 -03:00
|
|
|
for (i = 0; i < op->ob_size; i++) {
|
|
|
|
if (i > 0)
|
1990-10-14 09:07:46 -03:00
|
|
|
fprintf(fp, ", ");
|
1997-05-02 00:12:38 -03:00
|
|
|
if (PyObject_Print(op->ob_item[i], fp, 0) != 0)
|
1991-06-07 19:59:30 -03:00
|
|
|
return -1;
|
1990-10-14 09:07:46 -03:00
|
|
|
}
|
|
|
|
if (op->ob_size == 1)
|
|
|
|
fprintf(fp, ",");
|
|
|
|
fprintf(fp, ")");
|
1991-06-07 19:59:30 -03:00
|
|
|
return 0;
|
1990-10-14 09:07:46 -03:00
|
|
|
}
|
|
|
|
|
1997-05-02 00:12:38 -03:00
|
|
|
static PyObject *
|
1990-10-14 09:07:46 -03:00
|
|
|
tuplerepr(v)
|
1997-05-02 00:12:38 -03:00
|
|
|
PyTupleObject *v;
|
1990-10-14 09:07:46 -03:00
|
|
|
{
|
1997-05-02 00:12:38 -03:00
|
|
|
PyObject *s, *comma;
|
1990-10-14 09:07:46 -03:00
|
|
|
int i;
|
1997-05-02 00:12:38 -03:00
|
|
|
s = PyString_FromString("(");
|
|
|
|
comma = PyString_FromString(", ");
|
1990-10-14 09:07:46 -03:00
|
|
|
for (i = 0; i < v->ob_size && s != NULL; i++) {
|
|
|
|
if (i > 0)
|
1997-05-02 00:12:38 -03:00
|
|
|
PyString_Concat(&s, comma);
|
|
|
|
PyString_ConcatAndDel(&s, PyObject_Repr(v->ob_item[i]));
|
1990-10-14 09:07:46 -03:00
|
|
|
}
|
1997-05-02 00:12:38 -03:00
|
|
|
Py_DECREF(comma);
|
1994-08-30 05:27:36 -03:00
|
|
|
if (v->ob_size == 1)
|
1997-05-02 00:12:38 -03:00
|
|
|
PyString_ConcatAndDel(&s, PyString_FromString(","));
|
|
|
|
PyString_ConcatAndDel(&s, PyString_FromString(")"));
|
1990-10-14 09:07:46 -03:00
|
|
|
return s;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
tuplecompare(v, w)
|
1997-05-02 00:12:38 -03:00
|
|
|
register PyTupleObject *v, *w;
|
1990-10-14 09:07:46 -03:00
|
|
|
{
|
|
|
|
register int len =
|
|
|
|
(v->ob_size < w->ob_size) ? v->ob_size : w->ob_size;
|
|
|
|
register int i;
|
|
|
|
for (i = 0; i < len; i++) {
|
1997-05-02 00:12:38 -03:00
|
|
|
int cmp = PyObject_Compare(v->ob_item[i], w->ob_item[i]);
|
1990-10-14 09:07:46 -03:00
|
|
|
if (cmp != 0)
|
|
|
|
return cmp;
|
|
|
|
}
|
|
|
|
return v->ob_size - w->ob_size;
|
|
|
|
}
|
|
|
|
|
1993-03-29 06:43:31 -04:00
|
|
|
static long
|
|
|
|
tuplehash(v)
|
1997-05-02 00:12:38 -03:00
|
|
|
PyTupleObject *v;
|
1993-03-29 06:43:31 -04:00
|
|
|
{
|
|
|
|
register long x, y;
|
|
|
|
register int len = v->ob_size;
|
1997-05-02 00:12:38 -03:00
|
|
|
register PyObject **p;
|
1993-03-29 06:43:31 -04:00
|
|
|
x = 0x345678L;
|
|
|
|
p = v->ob_item;
|
|
|
|
while (--len >= 0) {
|
1997-05-02 00:12:38 -03:00
|
|
|
y = PyObject_Hash(*p++);
|
1993-03-29 06:43:31 -04:00
|
|
|
if (y == -1)
|
|
|
|
return -1;
|
1996-12-16 13:55:46 -04:00
|
|
|
x = (1000003*x) ^ y;
|
1993-03-29 06:43:31 -04:00
|
|
|
}
|
|
|
|
x ^= v->ob_size;
|
|
|
|
if (x == -1)
|
|
|
|
x = -2;
|
|
|
|
return x;
|
|
|
|
}
|
|
|
|
|
1990-10-14 09:07:46 -03:00
|
|
|
static int
|
|
|
|
tuplelength(a)
|
1997-05-02 00:12:38 -03:00
|
|
|
PyTupleObject *a;
|
1990-10-14 09:07:46 -03:00
|
|
|
{
|
|
|
|
return a->ob_size;
|
|
|
|
}
|
|
|
|
|
2000-04-27 18:41:03 -03:00
|
|
|
static int
|
|
|
|
tuplecontains(a, el)
|
|
|
|
PyTupleObject *a;
|
|
|
|
PyObject *el;
|
|
|
|
{
|
|
|
|
int i, cmp;
|
|
|
|
|
|
|
|
for (i = 0; i < a->ob_size; ++i) {
|
|
|
|
cmp = PyObject_Compare(el, PyTuple_GET_ITEM(a, i));
|
|
|
|
if (cmp == 0)
|
|
|
|
return 1;
|
|
|
|
if (PyErr_Occurred())
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
1997-05-02 00:12:38 -03:00
|
|
|
static PyObject *
|
1990-10-14 09:07:46 -03:00
|
|
|
tupleitem(a, i)
|
1997-05-02 00:12:38 -03:00
|
|
|
register PyTupleObject *a;
|
1990-10-14 09:07:46 -03:00
|
|
|
register int i;
|
|
|
|
{
|
|
|
|
if (i < 0 || i >= a->ob_size) {
|
1997-05-02 00:12:38 -03:00
|
|
|
PyErr_SetString(PyExc_IndexError, "tuple index out of range");
|
1990-10-14 09:07:46 -03:00
|
|
|
return NULL;
|
|
|
|
}
|
1997-05-02 00:12:38 -03:00
|
|
|
Py_INCREF(a->ob_item[i]);
|
1990-10-14 09:07:46 -03:00
|
|
|
return a->ob_item[i];
|
|
|
|
}
|
|
|
|
|
1997-05-02 00:12:38 -03:00
|
|
|
static PyObject *
|
1990-10-14 09:07:46 -03:00
|
|
|
tupleslice(a, ilow, ihigh)
|
1997-05-02 00:12:38 -03:00
|
|
|
register PyTupleObject *a;
|
1990-10-14 09:07:46 -03:00
|
|
|
register int ilow, ihigh;
|
|
|
|
{
|
1997-05-02 00:12:38 -03:00
|
|
|
register PyTupleObject *np;
|
1990-10-14 09:07:46 -03:00
|
|
|
register int i;
|
|
|
|
if (ilow < 0)
|
|
|
|
ilow = 0;
|
|
|
|
if (ihigh > a->ob_size)
|
|
|
|
ihigh = a->ob_size;
|
|
|
|
if (ihigh < ilow)
|
|
|
|
ihigh = ilow;
|
|
|
|
if (ilow == 0 && ihigh == a->ob_size) {
|
|
|
|
/* XXX can only do this if tuples are immutable! */
|
1997-05-02 00:12:38 -03:00
|
|
|
Py_INCREF(a);
|
|
|
|
return (PyObject *)a;
|
1990-10-14 09:07:46 -03:00
|
|
|
}
|
1997-05-02 00:12:38 -03:00
|
|
|
np = (PyTupleObject *)PyTuple_New(ihigh - ilow);
|
1990-10-14 09:07:46 -03:00
|
|
|
if (np == NULL)
|
|
|
|
return NULL;
|
|
|
|
for (i = ilow; i < ihigh; i++) {
|
1997-05-02 00:12:38 -03:00
|
|
|
PyObject *v = a->ob_item[i];
|
|
|
|
Py_INCREF(v);
|
1990-10-14 09:07:46 -03:00
|
|
|
np->ob_item[i - ilow] = v;
|
|
|
|
}
|
1997-05-02 00:12:38 -03:00
|
|
|
return (PyObject *)np;
|
1990-10-14 09:07:46 -03:00
|
|
|
}
|
|
|
|
|
1997-05-02 00:12:38 -03:00
|
|
|
PyObject *
|
|
|
|
PyTuple_GetSlice(op, i, j)
|
|
|
|
PyObject *op;
|
1992-01-14 14:45:33 -04:00
|
|
|
int i, j;
|
|
|
|
{
|
1997-05-02 00:12:38 -03:00
|
|
|
if (op == NULL || !PyTuple_Check(op)) {
|
|
|
|
PyErr_BadInternalCall();
|
1992-01-14 14:45:33 -04:00
|
|
|
return NULL;
|
|
|
|
}
|
1997-05-02 00:12:38 -03:00
|
|
|
return tupleslice((PyTupleObject *)op, i, j);
|
1992-01-14 14:45:33 -04:00
|
|
|
}
|
|
|
|
|
1997-05-02 00:12:38 -03:00
|
|
|
static PyObject *
|
1990-10-14 09:07:46 -03:00
|
|
|
tupleconcat(a, bb)
|
1997-05-02 00:12:38 -03:00
|
|
|
register PyTupleObject *a;
|
|
|
|
register PyObject *bb;
|
1990-10-14 09:07:46 -03:00
|
|
|
{
|
|
|
|
register int size;
|
|
|
|
register int i;
|
1997-05-02 00:12:38 -03:00
|
|
|
PyTupleObject *np;
|
|
|
|
if (!PyTuple_Check(bb)) {
|
2000-06-01 00:12:13 -03:00
|
|
|
PyErr_Format(PyExc_TypeError,
|
2000-06-16 14:05:57 -03:00
|
|
|
"can only concatenate tuple (not \"%.200s\") to tuple",
|
2000-06-01 00:12:13 -03:00
|
|
|
bb->ob_type->tp_name);
|
1990-10-14 09:07:46 -03:00
|
|
|
return NULL;
|
|
|
|
}
|
1997-05-02 00:12:38 -03:00
|
|
|
#define b ((PyTupleObject *)bb)
|
1990-10-14 09:07:46 -03:00
|
|
|
size = a->ob_size + b->ob_size;
|
1997-05-02 00:12:38 -03:00
|
|
|
np = (PyTupleObject *) PyTuple_New(size);
|
1990-10-14 09:07:46 -03:00
|
|
|
if (np == NULL) {
|
1991-06-07 19:59:30 -03:00
|
|
|
return NULL;
|
1990-10-14 09:07:46 -03:00
|
|
|
}
|
|
|
|
for (i = 0; i < a->ob_size; i++) {
|
1997-05-02 00:12:38 -03:00
|
|
|
PyObject *v = a->ob_item[i];
|
|
|
|
Py_INCREF(v);
|
1990-10-14 09:07:46 -03:00
|
|
|
np->ob_item[i] = v;
|
|
|
|
}
|
|
|
|
for (i = 0; i < b->ob_size; i++) {
|
1997-05-02 00:12:38 -03:00
|
|
|
PyObject *v = b->ob_item[i];
|
|
|
|
Py_INCREF(v);
|
1990-10-14 09:07:46 -03:00
|
|
|
np->ob_item[i + a->ob_size] = v;
|
|
|
|
}
|
1997-05-02 00:12:38 -03:00
|
|
|
return (PyObject *)np;
|
1990-10-14 09:07:46 -03:00
|
|
|
#undef b
|
|
|
|
}
|
|
|
|
|
1997-05-02 00:12:38 -03:00
|
|
|
static PyObject *
|
1991-06-04 16:35:24 -03:00
|
|
|
tuplerepeat(a, n)
|
1997-05-02 00:12:38 -03:00
|
|
|
PyTupleObject *a;
|
1991-06-04 16:35:24 -03:00
|
|
|
int n;
|
|
|
|
{
|
|
|
|
int i, j;
|
|
|
|
int size;
|
1997-05-02 00:12:38 -03:00
|
|
|
PyTupleObject *np;
|
|
|
|
PyObject **p;
|
1991-06-04 16:35:24 -03:00
|
|
|
if (n < 0)
|
|
|
|
n = 0;
|
1999-07-12 20:06:58 -03:00
|
|
|
if (a->ob_size == 0 || n == 1) {
|
1991-06-04 16:35:24 -03:00
|
|
|
/* Since tuples are immutable, we can return a shared
|
|
|
|
copy in this case */
|
1997-05-02 00:12:38 -03:00
|
|
|
Py_INCREF(a);
|
|
|
|
return (PyObject *)a;
|
1991-06-04 16:35:24 -03:00
|
|
|
}
|
|
|
|
size = a->ob_size * n;
|
1999-07-13 02:41:12 -03:00
|
|
|
if (size/a->ob_size != n)
|
1999-07-12 20:06:58 -03:00
|
|
|
return PyErr_NoMemory();
|
1997-05-02 00:12:38 -03:00
|
|
|
np = (PyTupleObject *) PyTuple_New(size);
|
1991-06-04 16:35:24 -03:00
|
|
|
if (np == NULL)
|
|
|
|
return NULL;
|
|
|
|
p = np->ob_item;
|
|
|
|
for (i = 0; i < n; i++) {
|
|
|
|
for (j = 0; j < a->ob_size; j++) {
|
|
|
|
*p = a->ob_item[j];
|
1997-05-02 00:12:38 -03:00
|
|
|
Py_INCREF(*p);
|
1991-06-04 16:35:24 -03:00
|
|
|
p++;
|
|
|
|
}
|
|
|
|
}
|
1997-05-02 00:12:38 -03:00
|
|
|
return (PyObject *) np;
|
1991-06-04 16:35:24 -03:00
|
|
|
}
|
|
|
|
|
2000-06-23 11:18:11 -03:00
|
|
|
static int
|
|
|
|
tupletraverse(PyTupleObject *o, visitproc visit, void *arg)
|
|
|
|
{
|
|
|
|
int i, err;
|
|
|
|
PyObject *x;
|
|
|
|
|
|
|
|
for (i = o->ob_size; --i >= 0; ) {
|
|
|
|
x = o->ob_item[i];
|
|
|
|
if (x != NULL) {
|
|
|
|
err = visit(x, arg);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
1997-05-02 00:12:38 -03:00
|
|
|
static PySequenceMethods tuple_as_sequence = {
|
1994-08-30 05:27:36 -03:00
|
|
|
(inquiry)tuplelength, /*sq_length*/
|
|
|
|
(binaryfunc)tupleconcat, /*sq_concat*/
|
|
|
|
(intargfunc)tuplerepeat, /*sq_repeat*/
|
|
|
|
(intargfunc)tupleitem, /*sq_item*/
|
|
|
|
(intintargfunc)tupleslice, /*sq_slice*/
|
1990-10-14 09:07:46 -03:00
|
|
|
0, /*sq_ass_item*/
|
|
|
|
0, /*sq_ass_slice*/
|
2000-04-27 18:41:03 -03:00
|
|
|
(objobjproc)tuplecontains, /*sq_contains*/
|
1990-10-14 09:07:46 -03:00
|
|
|
};
|
|
|
|
|
1997-05-02 00:12:38 -03:00
|
|
|
PyTypeObject PyTuple_Type = {
|
|
|
|
PyObject_HEAD_INIT(&PyType_Type)
|
1990-10-14 09:07:46 -03:00
|
|
|
0,
|
|
|
|
"tuple",
|
2000-06-30 02:02:53 -03:00
|
|
|
sizeof(PyTupleObject) - sizeof(PyObject *) + PyGC_HEAD_SIZE,
|
1997-05-02 00:12:38 -03:00
|
|
|
sizeof(PyObject *),
|
1994-08-30 05:27:36 -03:00
|
|
|
(destructor)tupledealloc, /*tp_dealloc*/
|
|
|
|
(printfunc)tupleprint, /*tp_print*/
|
1990-10-14 09:07:46 -03:00
|
|
|
0, /*tp_getattr*/
|
|
|
|
0, /*tp_setattr*/
|
1994-08-30 05:27:36 -03:00
|
|
|
(cmpfunc)tuplecompare, /*tp_compare*/
|
|
|
|
(reprfunc)tuplerepr, /*tp_repr*/
|
1990-10-14 09:07:46 -03:00
|
|
|
0, /*tp_as_number*/
|
|
|
|
&tuple_as_sequence, /*tp_as_sequence*/
|
|
|
|
0, /*tp_as_mapping*/
|
1994-08-30 05:27:36 -03:00
|
|
|
(hashfunc)tuplehash, /*tp_hash*/
|
2000-06-15 11:50:20 -03:00
|
|
|
0, /*tp_call*/
|
|
|
|
0, /*tp_str*/
|
|
|
|
0, /*tp_getattro*/
|
|
|
|
0, /*tp_setattro*/
|
|
|
|
0, /*tp_as_buffer*/
|
2000-06-23 16:37:02 -03:00
|
|
|
Py_TPFLAGS_DEFAULT | Py_TPFLAGS_GC, /*tp_flags*/
|
2000-06-23 11:18:11 -03:00
|
|
|
0, /*tp_doc*/
|
|
|
|
(traverseproc)tupletraverse, /* tp_traverse */
|
1990-10-14 09:07:46 -03:00
|
|
|
};
|
1993-10-26 14:58:25 -03:00
|
|
|
|
|
|
|
/* The following function breaks the notion that tuples are immutable:
|
|
|
|
it changes the size of a tuple. We get away with this only if there
|
|
|
|
is only one module referencing the object. You can also think of it
|
|
|
|
as creating a new tuple object and destroying the old one, only
|
|
|
|
more efficiently. In any case, don't use this if the tuple may
|
1993-11-01 09:46:50 -04:00
|
|
|
already be known to some other part of the code...
|
|
|
|
If last_is_sticky is set, the tuple will grow or shrink at the
|
|
|
|
front, otherwise it will grow or shrink at the end. */
|
1993-10-26 14:58:25 -03:00
|
|
|
|
|
|
|
int
|
1997-05-02 00:12:38 -03:00
|
|
|
_PyTuple_Resize(pv, newsize, last_is_sticky)
|
|
|
|
PyObject **pv;
|
1993-10-26 14:58:25 -03:00
|
|
|
int newsize;
|
1993-11-01 09:46:50 -04:00
|
|
|
int last_is_sticky;
|
1993-10-26 14:58:25 -03:00
|
|
|
{
|
1997-05-02 00:12:38 -03:00
|
|
|
register PyTupleObject *v;
|
|
|
|
register PyTupleObject *sv;
|
1993-11-01 09:46:50 -04:00
|
|
|
int i;
|
|
|
|
int sizediff;
|
|
|
|
|
1997-05-02 00:12:38 -03:00
|
|
|
v = (PyTupleObject *) *pv;
|
|
|
|
if (v == NULL || !PyTuple_Check(v) || v->ob_refcnt != 1) {
|
1993-10-26 14:58:25 -03:00
|
|
|
*pv = 0;
|
1997-05-02 00:12:38 -03:00
|
|
|
Py_DECREF(v);
|
|
|
|
PyErr_BadInternalCall();
|
1993-10-26 14:58:25 -03:00
|
|
|
return -1;
|
|
|
|
}
|
1995-08-04 01:05:10 -03:00
|
|
|
sizediff = newsize - v->ob_size;
|
1993-11-01 09:46:50 -04:00
|
|
|
if (sizediff == 0)
|
|
|
|
return 0;
|
1993-10-26 14:58:25 -03:00
|
|
|
/* XXX UNREF/NEWREF interface should be more symmetrical */
|
1996-05-23 19:46:51 -03:00
|
|
|
#ifdef Py_REF_DEBUG
|
1995-03-29 12:57:48 -04:00
|
|
|
--_Py_RefTotal;
|
1993-10-26 14:58:25 -03:00
|
|
|
#endif
|
2000-01-20 18:32:56 -04:00
|
|
|
_Py_ForgetReference((PyObject *)v);
|
1993-11-01 09:46:50 -04:00
|
|
|
if (last_is_sticky && sizediff < 0) {
|
1997-05-02 00:12:38 -03:00
|
|
|
/* shrinking:
|
|
|
|
move entries to the front and zero moved entries */
|
1993-11-01 09:46:50 -04:00
|
|
|
for (i = 0; i < newsize; i++) {
|
1997-05-02 00:12:38 -03:00
|
|
|
Py_XDECREF(v->ob_item[i]);
|
1993-11-01 09:46:50 -04:00
|
|
|
v->ob_item[i] = v->ob_item[i - sizediff];
|
|
|
|
v->ob_item[i - sizediff] = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
for (i = newsize; i < v->ob_size; i++) {
|
1997-05-02 00:12:38 -03:00
|
|
|
Py_XDECREF(v->ob_item[i]);
|
1993-11-01 09:46:50 -04:00
|
|
|
v->ob_item[i] = NULL;
|
|
|
|
}
|
Patch by Charles G Waldman to avoid a sneaky memory leak in
_PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton
to limit the size of the free lists is also merged into this patch.
Charles wrote initially:
"""
Test Case: run the following code:
class Nothing:
def __len__(self):
return 5
def __getitem__(self, i):
if i < 3:
return i
else:
raise IndexError, i
def g(a,*b,**c):
return
for x in xrange(1000000):
g(*Nothing())
and watch Python's memory use go up and up.
Diagnosis:
The analysis begins with the call to PySequence_Tuple at line 1641 in
ceval.c - the argument to g is seen to be a sequence but not a tuple,
so it needs to be converted from an abstract sequence to a concrete
tuple. PySequence_Tuple starts off by creating a new tuple of length
5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements
were assigned, _PyTuple_Resize is called to make the 5-tuple into a
3-tuple. When we're all done the 3-tuple is decrefed, but rather than
being freed it is placed on the free_tuples cache.
The basic problem is that the 3-tuples are being added to the cache
but never picked up again, since _PyTuple_Resize doesn't make use of
the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and
there is already a 3-tuple in free_tuples[3], instead of using this
tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It
would more efficient to use the existing 3-tuple and cache the
5-tuple.
By making _PyTuple_Resize aware of the free_tuples (just as
PyTuple_New), we not only save a few calls to realloc, but also
prevent this misbehavior whereby tuples are being added to the
free_tuples list but never properly "recycled".
"""
And later:
"""
This patch replaces my submission of Sun, 16 Apr and addresses Jeremy
Hylton's suggestions that we also limit the size of the free tuple
list. I chose 2000 as the maximum number of tuples of any particular
size to save.
There was also a problem with the previous version of this patch
causing a core dump if Python was built with Py_TRACE_REFS. This is
fixed in the below version of the patch, which uses tupledealloc
instead of _Py_Dealloc.
"""
2000-04-21 18:15:05 -03:00
|
|
|
#if MAXSAVESIZE > 0
|
|
|
|
if (newsize == 0 && free_tuples[0]) {
|
|
|
|
num_free_tuples[0]--;
|
|
|
|
sv = free_tuples[0];
|
|
|
|
sv->ob_size = 0;
|
|
|
|
Py_INCREF(sv);
|
|
|
|
#ifdef COUNT_ALLOCS
|
|
|
|
tuple_zero_allocs++;
|
|
|
|
#endif
|
|
|
|
tupledealloc(v);
|
|
|
|
*pv = (PyObject*) sv;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if (0 < newsize && newsize < MAXSAVESIZE &&
|
|
|
|
(sv = free_tuples[newsize]) != NULL)
|
|
|
|
{
|
|
|
|
free_tuples[newsize] = (PyTupleObject *) sv->ob_item[0];
|
|
|
|
num_free_tuples[newsize]--;
|
|
|
|
#ifdef COUNT_ALLOCS
|
|
|
|
fast_tuple_allocs++;
|
|
|
|
#endif
|
|
|
|
#ifdef Py_TRACE_REFS
|
|
|
|
sv->ob_type = &PyTuple_Type;
|
|
|
|
#endif
|
|
|
|
for (i = 0; i < newsize; ++i){
|
|
|
|
sv->ob_item[i] = v->ob_item[i];
|
|
|
|
v->ob_item[i] = NULL;
|
|
|
|
}
|
|
|
|
sv->ob_size = v->ob_size;
|
|
|
|
tupledealloc(v);
|
|
|
|
*pv = (PyObject *) sv;
|
|
|
|
} else
|
|
|
|
#endif
|
|
|
|
{
|
2000-06-30 02:02:53 -03:00
|
|
|
#ifdef WITH_CYCLE_GC
|
|
|
|
PyGC_Head *g = PyObject_AS_GC((PyObject *)v);
|
|
|
|
PyObject_GC_Fini((PyObject *)v);
|
|
|
|
sv = (PyTupleObject *)
|
|
|
|
PyObject_REALLOC((char *)g, sizeof(PyTupleObject)
|
|
|
|
+ PyGC_HEAD_SIZE
|
|
|
|
+ newsize * sizeof(PyObject *));
|
|
|
|
if (g == NULL) {
|
|
|
|
sv = NULL;
|
|
|
|
} else {
|
|
|
|
sv = (PyTupleObject *)PyObject_FROM_GC(g);
|
|
|
|
}
|
|
|
|
#else
|
Patch by Charles G Waldman to avoid a sneaky memory leak in
_PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton
to limit the size of the free lists is also merged into this patch.
Charles wrote initially:
"""
Test Case: run the following code:
class Nothing:
def __len__(self):
return 5
def __getitem__(self, i):
if i < 3:
return i
else:
raise IndexError, i
def g(a,*b,**c):
return
for x in xrange(1000000):
g(*Nothing())
and watch Python's memory use go up and up.
Diagnosis:
The analysis begins with the call to PySequence_Tuple at line 1641 in
ceval.c - the argument to g is seen to be a sequence but not a tuple,
so it needs to be converted from an abstract sequence to a concrete
tuple. PySequence_Tuple starts off by creating a new tuple of length
5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements
were assigned, _PyTuple_Resize is called to make the 5-tuple into a
3-tuple. When we're all done the 3-tuple is decrefed, but rather than
being freed it is placed on the free_tuples cache.
The basic problem is that the 3-tuples are being added to the cache
but never picked up again, since _PyTuple_Resize doesn't make use of
the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and
there is already a 3-tuple in free_tuples[3], instead of using this
tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It
would more efficient to use the existing 3-tuple and cache the
5-tuple.
By making _PyTuple_Resize aware of the free_tuples (just as
PyTuple_New), we not only save a few calls to realloc, but also
prevent this misbehavior whereby tuples are being added to the
free_tuples list but never properly "recycled".
"""
And later:
"""
This patch replaces my submission of Sun, 16 Apr and addresses Jeremy
Hylton's suggestions that we also limit the size of the free tuple
list. I chose 2000 as the maximum number of tuples of any particular
size to save.
There was also a problem with the previous version of this patch
causing a core dump if Python was built with Py_TRACE_REFS. This is
fixed in the below version of the patch, which uses tupledealloc
instead of _Py_Dealloc.
"""
2000-04-21 18:15:05 -03:00
|
|
|
sv = (PyTupleObject *)
|
2000-06-23 16:37:02 -03:00
|
|
|
PyObject_REALLOC((char *)v, sizeof(PyTupleObject)
|
2000-06-30 02:02:53 -03:00
|
|
|
+ PyGC_HEAD_SIZE
|
2000-06-23 16:37:02 -03:00
|
|
|
+ newsize * sizeof(PyObject *));
|
2000-06-30 02:02:53 -03:00
|
|
|
#endif
|
Patch by Charles G Waldman to avoid a sneaky memory leak in
_PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton
to limit the size of the free lists is also merged into this patch.
Charles wrote initially:
"""
Test Case: run the following code:
class Nothing:
def __len__(self):
return 5
def __getitem__(self, i):
if i < 3:
return i
else:
raise IndexError, i
def g(a,*b,**c):
return
for x in xrange(1000000):
g(*Nothing())
and watch Python's memory use go up and up.
Diagnosis:
The analysis begins with the call to PySequence_Tuple at line 1641 in
ceval.c - the argument to g is seen to be a sequence but not a tuple,
so it needs to be converted from an abstract sequence to a concrete
tuple. PySequence_Tuple starts off by creating a new tuple of length
5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements
were assigned, _PyTuple_Resize is called to make the 5-tuple into a
3-tuple. When we're all done the 3-tuple is decrefed, but rather than
being freed it is placed on the free_tuples cache.
The basic problem is that the 3-tuples are being added to the cache
but never picked up again, since _PyTuple_Resize doesn't make use of
the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and
there is already a 3-tuple in free_tuples[3], instead of using this
tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It
would more efficient to use the existing 3-tuple and cache the
5-tuple.
By making _PyTuple_Resize aware of the free_tuples (just as
PyTuple_New), we not only save a few calls to realloc, but also
prevent this misbehavior whereby tuples are being added to the
free_tuples list but never properly "recycled".
"""
And later:
"""
This patch replaces my submission of Sun, 16 Apr and addresses Jeremy
Hylton's suggestions that we also limit the size of the free tuple
list. I chose 2000 as the maximum number of tuples of any particular
size to save.
There was also a problem with the previous version of this patch
causing a core dump if Python was built with Py_TRACE_REFS. This is
fixed in the below version of the patch, which uses tupledealloc
instead of _Py_Dealloc.
"""
2000-04-21 18:15:05 -03:00
|
|
|
*pv = (PyObject *) sv;
|
|
|
|
if (sv == NULL) {
|
2000-06-30 02:02:53 -03:00
|
|
|
PyObject_GC_Init((PyObject *)v);
|
2000-05-03 20:44:39 -03:00
|
|
|
PyObject_DEL(v);
|
Patch by Charles G Waldman to avoid a sneaky memory leak in
_PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton
to limit the size of the free lists is also merged into this patch.
Charles wrote initially:
"""
Test Case: run the following code:
class Nothing:
def __len__(self):
return 5
def __getitem__(self, i):
if i < 3:
return i
else:
raise IndexError, i
def g(a,*b,**c):
return
for x in xrange(1000000):
g(*Nothing())
and watch Python's memory use go up and up.
Diagnosis:
The analysis begins with the call to PySequence_Tuple at line 1641 in
ceval.c - the argument to g is seen to be a sequence but not a tuple,
so it needs to be converted from an abstract sequence to a concrete
tuple. PySequence_Tuple starts off by creating a new tuple of length
5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements
were assigned, _PyTuple_Resize is called to make the 5-tuple into a
3-tuple. When we're all done the 3-tuple is decrefed, but rather than
being freed it is placed on the free_tuples cache.
The basic problem is that the 3-tuples are being added to the cache
but never picked up again, since _PyTuple_Resize doesn't make use of
the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and
there is already a 3-tuple in free_tuples[3], instead of using this
tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It
would more efficient to use the existing 3-tuple and cache the
5-tuple.
By making _PyTuple_Resize aware of the free_tuples (just as
PyTuple_New), we not only save a few calls to realloc, but also
prevent this misbehavior whereby tuples are being added to the
free_tuples list but never properly "recycled".
"""
And later:
"""
This patch replaces my submission of Sun, 16 Apr and addresses Jeremy
Hylton's suggestions that we also limit the size of the free tuple
list. I chose 2000 as the maximum number of tuples of any particular
size to save.
There was also a problem with the previous version of this patch
causing a core dump if Python was built with Py_TRACE_REFS. This is
fixed in the below version of the patch, which uses tupledealloc
instead of _Py_Dealloc.
"""
2000-04-21 18:15:05 -03:00
|
|
|
PyErr_NoMemory();
|
|
|
|
return -1;
|
|
|
|
}
|
1993-10-26 14:58:25 -03:00
|
|
|
}
|
2000-01-20 18:32:56 -04:00
|
|
|
_Py_NewReference((PyObject *)sv);
|
1993-11-01 09:46:50 -04:00
|
|
|
for (i = sv->ob_size; i < newsize; i++)
|
|
|
|
sv->ob_item[i] = NULL;
|
|
|
|
if (last_is_sticky && sizediff > 0) {
|
|
|
|
/* growing: move entries to the end and zero moved entries */
|
|
|
|
for (i = newsize - 1; i >= sizediff; i--) {
|
|
|
|
sv->ob_item[i] = sv->ob_item[i - sizediff];
|
|
|
|
sv->ob_item[i - sizediff] = NULL;
|
|
|
|
}
|
|
|
|
}
|
2000-06-30 02:02:53 -03:00
|
|
|
PyObject_GC_Init(sv);
|
1993-11-01 09:46:50 -04:00
|
|
|
sv->ob_size = newsize;
|
1993-10-26 14:58:25 -03:00
|
|
|
return 0;
|
|
|
|
}
|
1997-08-04 23:16:08 -03:00
|
|
|
|
|
|
|
void
|
|
|
|
PyTuple_Fini()
|
|
|
|
{
|
|
|
|
#if MAXSAVESIZE > 0
|
|
|
|
int i;
|
|
|
|
|
|
|
|
Py_XDECREF(free_tuples[0]);
|
|
|
|
free_tuples[0] = NULL;
|
|
|
|
|
|
|
|
for (i = 1; i < MAXSAVESIZE; i++) {
|
|
|
|
PyTupleObject *p, *q;
|
|
|
|
p = free_tuples[i];
|
|
|
|
free_tuples[i] = NULL;
|
|
|
|
while (p) {
|
|
|
|
q = p;
|
|
|
|
p = (PyTupleObject *)(p->ob_item[0]);
|
2000-05-03 20:44:39 -03:00
|
|
|
PyObject_DEL(q);
|
1997-08-04 23:16:08 -03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|