2000-09-03 20:47:08 -03:00
|
|
|
/* Parse tree node implementation */
|
|
|
|
|
2000-09-26 03:11:54 -03:00
|
|
|
#include "Python.h"
|
2000-09-03 20:47:08 -03:00
|
|
|
#include "node.h"
|
|
|
|
#include "errcode.h"
|
|
|
|
|
1990-10-14 09:07:46 -03:00
|
|
|
node *
|
2000-07-22 16:20:54 -03:00
|
|
|
PyNode_New(int type)
|
1990-10-14 09:07:46 -03:00
|
|
|
{
|
2002-08-04 03:28:21 -03:00
|
|
|
node *n = (node *) PyObject_MALLOC(1 * sizeof(node));
|
1990-10-14 09:07:46 -03:00
|
|
|
if (n == NULL)
|
|
|
|
return NULL;
|
|
|
|
n->n_type = type;
|
|
|
|
n->n_str = NULL;
|
1990-12-20 11:06:42 -04:00
|
|
|
n->n_lineno = 0;
|
1990-10-14 09:07:46 -03:00
|
|
|
n->n_nchildren = 0;
|
|
|
|
n->n_child = NULL;
|
|
|
|
return n;
|
|
|
|
}
|
|
|
|
|
2002-07-08 16:11:07 -03:00
|
|
|
/* See comments at XXXROUNDUP below. Returns -1 on overflow. */
|
PyNode_AddChild(): Do aggressive over-allocation when the number of
children gets large, to avoid severe platform realloc() degeneration
in extreme cases (like test_longexp).
Bugfix candidate.
This was doing extremely timid over-allocation, just rounding up to the
nearest multiple of 3. Now so long as the number of children is <= 128,
it rounds up to a multiple of 4 but via a much faster method. When the
number of children exceeds 128, though, and more space is needed, it
doubles the capacity. This is aggressive over-allocation.
SF patch <http://www.python.org/sf/578297> has Andrew MacIntyre using
PyMalloc in the parser to overcome platform malloc problems in
test_longexp on OS/2 EMX. Jack Jansen notes there that it didn't help
him on the Mac, because the Mac has problems with frequent ever-growing
reallocs, not just with gazillions of teensy mallocs. Win98 has no
visible problems with test_longexp, but I tried boosting the test-case
size and soon got "senseless" MemoryErrors out of it, and soon after
crashed the OS: as I've seen in many other contexts before, while the
Win98 realloc remains zippy in bad cases, it leads to extreme
fragmentation of user address space, to the point that the OS barfs.
I don't yet know whether this fixes Jack's Mac problems, but it does cure
Win98's problems when boosting the test case size. It also speeds
test_longexp in its unaltered state.
2002-07-08 03:32:09 -03:00
|
|
|
static int
|
|
|
|
fancy_roundup(int n)
|
|
|
|
{
|
|
|
|
/* Round up to the closest power of 2 >= n. */
|
|
|
|
int result = 256;
|
|
|
|
assert(n > 128);
|
2002-07-08 16:11:07 -03:00
|
|
|
while (result < n) {
|
PyNode_AddChild(): Do aggressive over-allocation when the number of
children gets large, to avoid severe platform realloc() degeneration
in extreme cases (like test_longexp).
Bugfix candidate.
This was doing extremely timid over-allocation, just rounding up to the
nearest multiple of 3. Now so long as the number of children is <= 128,
it rounds up to a multiple of 4 but via a much faster method. When the
number of children exceeds 128, though, and more space is needed, it
doubles the capacity. This is aggressive over-allocation.
SF patch <http://www.python.org/sf/578297> has Andrew MacIntyre using
PyMalloc in the parser to overcome platform malloc problems in
test_longexp on OS/2 EMX. Jack Jansen notes there that it didn't help
him on the Mac, because the Mac has problems with frequent ever-growing
reallocs, not just with gazillions of teensy mallocs. Win98 has no
visible problems with test_longexp, but I tried boosting the test-case
size and soon got "senseless" MemoryErrors out of it, and soon after
crashed the OS: as I've seen in many other contexts before, while the
Win98 realloc remains zippy in bad cases, it leads to extreme
fragmentation of user address space, to the point that the OS barfs.
I don't yet know whether this fixes Jack's Mac problems, but it does cure
Win98's problems when boosting the test case size. It also speeds
test_longexp in its unaltered state.
2002-07-08 03:32:09 -03:00
|
|
|
result <<= 1;
|
2002-07-08 16:11:07 -03:00
|
|
|
if (result <= 0)
|
|
|
|
return -1;
|
|
|
|
}
|
PyNode_AddChild(): Do aggressive over-allocation when the number of
children gets large, to avoid severe platform realloc() degeneration
in extreme cases (like test_longexp).
Bugfix candidate.
This was doing extremely timid over-allocation, just rounding up to the
nearest multiple of 3. Now so long as the number of children is <= 128,
it rounds up to a multiple of 4 but via a much faster method. When the
number of children exceeds 128, though, and more space is needed, it
doubles the capacity. This is aggressive over-allocation.
SF patch <http://www.python.org/sf/578297> has Andrew MacIntyre using
PyMalloc in the parser to overcome platform malloc problems in
test_longexp on OS/2 EMX. Jack Jansen notes there that it didn't help
him on the Mac, because the Mac has problems with frequent ever-growing
reallocs, not just with gazillions of teensy mallocs. Win98 has no
visible problems with test_longexp, but I tried boosting the test-case
size and soon got "senseless" MemoryErrors out of it, and soon after
crashed the OS: as I've seen in many other contexts before, while the
Win98 realloc remains zippy in bad cases, it leads to extreme
fragmentation of user address space, to the point that the OS barfs.
I don't yet know whether this fixes Jack's Mac problems, but it does cure
Win98's problems when boosting the test case size. It also speeds
test_longexp in its unaltered state.
2002-07-08 03:32:09 -03:00
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* A gimmick to make massive numbers of reallocs quicker. The result is
|
2002-07-15 14:58:03 -03:00
|
|
|
* a number >= the input. In PyNode_AddChild, it's used like so, when
|
|
|
|
* we're about to add child number current_size + 1:
|
|
|
|
*
|
|
|
|
* if XXXROUNDUP(current_size) < XXXROUNDUP(current_size + 1):
|
|
|
|
* allocate space for XXXROUNDUP(current_size + 1) total children
|
|
|
|
* else:
|
|
|
|
* we already have enough space
|
|
|
|
*
|
|
|
|
* Since a node starts out empty, we must have
|
|
|
|
*
|
|
|
|
* XXXROUNDUP(0) < XXXROUNDUP(1)
|
|
|
|
*
|
|
|
|
* so that we allocate space for the first child. One-child nodes are very
|
|
|
|
* common (presumably that would change if we used a more abstract form
|
|
|
|
* of syntax tree), so to avoid wasting memory it's desirable that
|
|
|
|
* XXXROUNDUP(1) == 1. That in turn forces XXXROUNDUP(0) == 0.
|
|
|
|
*
|
|
|
|
* Else for 2 <= n <= 128, we round up to the closest multiple of 4. Why 4?
|
|
|
|
* Rounding up to a multiple of an exact power of 2 is very efficient, and
|
|
|
|
* most nodes with more than one child have <= 4 kids.
|
|
|
|
*
|
|
|
|
* Else we call fancy_roundup() to grow proportionately to n. We've got an
|
PyNode_AddChild(): Do aggressive over-allocation when the number of
children gets large, to avoid severe platform realloc() degeneration
in extreme cases (like test_longexp).
Bugfix candidate.
This was doing extremely timid over-allocation, just rounding up to the
nearest multiple of 3. Now so long as the number of children is <= 128,
it rounds up to a multiple of 4 but via a much faster method. When the
number of children exceeds 128, though, and more space is needed, it
doubles the capacity. This is aggressive over-allocation.
SF patch <http://www.python.org/sf/578297> has Andrew MacIntyre using
PyMalloc in the parser to overcome platform malloc problems in
test_longexp on OS/2 EMX. Jack Jansen notes there that it didn't help
him on the Mac, because the Mac has problems with frequent ever-growing
reallocs, not just with gazillions of teensy mallocs. Win98 has no
visible problems with test_longexp, but I tried boosting the test-case
size and soon got "senseless" MemoryErrors out of it, and soon after
crashed the OS: as I've seen in many other contexts before, while the
Win98 realloc remains zippy in bad cases, it leads to extreme
fragmentation of user address space, to the point that the OS barfs.
I don't yet know whether this fixes Jack's Mac problems, but it does cure
Win98's problems when boosting the test case size. It also speeds
test_longexp in its unaltered state.
2002-07-08 03:32:09 -03:00
|
|
|
* extreme case then (like test_longexp.py), and on many platforms doing
|
|
|
|
* anything less than proportional growth leads to exorbitant runtime
|
|
|
|
* (e.g., MacPython), or extreme fragmentation of user address space (e.g.,
|
|
|
|
* Win98).
|
2002-07-15 14:58:03 -03:00
|
|
|
*
|
|
|
|
* In a run of compileall across the 2.3a0 Lib directory, Andrew MacIntyre
|
2006-04-10 03:42:25 -03:00
|
|
|
* reported that, with this scheme, 89% of PyObject_REALLOC calls in
|
2002-07-15 14:58:03 -03:00
|
|
|
* PyNode_AddChild passed 1 for the size, and 9% passed 4. So this usually
|
|
|
|
* wastes very little memory, but is very effective at sidestepping
|
2006-06-06 14:10:41 -03:00
|
|
|
* platform-realloc disasters on vulnerable platforms.
|
2002-07-15 14:58:03 -03:00
|
|
|
*
|
|
|
|
* Note that this would be straightforward if a node stored its current
|
|
|
|
* capacity. The code is tricky to avoid that.
|
PyNode_AddChild(): Do aggressive over-allocation when the number of
children gets large, to avoid severe platform realloc() degeneration
in extreme cases (like test_longexp).
Bugfix candidate.
This was doing extremely timid over-allocation, just rounding up to the
nearest multiple of 3. Now so long as the number of children is <= 128,
it rounds up to a multiple of 4 but via a much faster method. When the
number of children exceeds 128, though, and more space is needed, it
doubles the capacity. This is aggressive over-allocation.
SF patch <http://www.python.org/sf/578297> has Andrew MacIntyre using
PyMalloc in the parser to overcome platform malloc problems in
test_longexp on OS/2 EMX. Jack Jansen notes there that it didn't help
him on the Mac, because the Mac has problems with frequent ever-growing
reallocs, not just with gazillions of teensy mallocs. Win98 has no
visible problems with test_longexp, but I tried boosting the test-case
size and soon got "senseless" MemoryErrors out of it, and soon after
crashed the OS: as I've seen in many other contexts before, while the
Win98 realloc remains zippy in bad cases, it leads to extreme
fragmentation of user address space, to the point that the OS barfs.
I don't yet know whether this fixes Jack's Mac problems, but it does cure
Win98's problems when boosting the test case size. It also speeds
test_longexp in its unaltered state.
2002-07-08 03:32:09 -03:00
|
|
|
*/
|
2002-07-15 14:58:03 -03:00
|
|
|
#define XXXROUNDUP(n) ((n) <= 1 ? (n) : \
|
|
|
|
(n) <= 128 ? (((n) + 3) & ~3) : \
|
PyNode_AddChild(): Do aggressive over-allocation when the number of
children gets large, to avoid severe platform realloc() degeneration
in extreme cases (like test_longexp).
Bugfix candidate.
This was doing extremely timid over-allocation, just rounding up to the
nearest multiple of 3. Now so long as the number of children is <= 128,
it rounds up to a multiple of 4 but via a much faster method. When the
number of children exceeds 128, though, and more space is needed, it
doubles the capacity. This is aggressive over-allocation.
SF patch <http://www.python.org/sf/578297> has Andrew MacIntyre using
PyMalloc in the parser to overcome platform malloc problems in
test_longexp on OS/2 EMX. Jack Jansen notes there that it didn't help
him on the Mac, because the Mac has problems with frequent ever-growing
reallocs, not just with gazillions of teensy mallocs. Win98 has no
visible problems with test_longexp, but I tried boosting the test-case
size and soon got "senseless" MemoryErrors out of it, and soon after
crashed the OS: as I've seen in many other contexts before, while the
Win98 realloc remains zippy in bad cases, it leads to extreme
fragmentation of user address space, to the point that the OS barfs.
I don't yet know whether this fixes Jack's Mac problems, but it does cure
Win98's problems when boosting the test case size. It also speeds
test_longexp in its unaltered state.
2002-07-08 03:32:09 -03:00
|
|
|
fancy_roundup(n))
|
|
|
|
|
1990-10-14 09:07:46 -03:00
|
|
|
|
2000-06-20 16:10:44 -03:00
|
|
|
int
|
2006-03-01 18:49:05 -04:00
|
|
|
PyNode_AddChild(register node *n1, int type, char *str, int lineno, int col_offset)
|
1990-10-14 09:07:46 -03:00
|
|
|
{
|
PyNode_AddChild(): Do aggressive over-allocation when the number of
children gets large, to avoid severe platform realloc() degeneration
in extreme cases (like test_longexp).
Bugfix candidate.
This was doing extremely timid over-allocation, just rounding up to the
nearest multiple of 3. Now so long as the number of children is <= 128,
it rounds up to a multiple of 4 but via a much faster method. When the
number of children exceeds 128, though, and more space is needed, it
doubles the capacity. This is aggressive over-allocation.
SF patch <http://www.python.org/sf/578297> has Andrew MacIntyre using
PyMalloc in the parser to overcome platform malloc problems in
test_longexp on OS/2 EMX. Jack Jansen notes there that it didn't help
him on the Mac, because the Mac has problems with frequent ever-growing
reallocs, not just with gazillions of teensy mallocs. Win98 has no
visible problems with test_longexp, but I tried boosting the test-case
size and soon got "senseless" MemoryErrors out of it, and soon after
crashed the OS: as I've seen in many other contexts before, while the
Win98 realloc remains zippy in bad cases, it leads to extreme
fragmentation of user address space, to the point that the OS barfs.
I don't yet know whether this fixes Jack's Mac problems, but it does cure
Win98's problems when boosting the test case size. It also speeds
test_longexp in its unaltered state.
2002-07-08 03:32:09 -03:00
|
|
|
const int nch = n1->n_nchildren;
|
|
|
|
int current_capacity;
|
|
|
|
int required_capacity;
|
|
|
|
node *n;
|
|
|
|
|
2000-08-23 21:32:09 -03:00
|
|
|
if (nch == INT_MAX || nch < 0)
|
2000-06-20 16:10:44 -03:00
|
|
|
return E_OVERFLOW;
|
PyNode_AddChild(): Do aggressive over-allocation when the number of
children gets large, to avoid severe platform realloc() degeneration
in extreme cases (like test_longexp).
Bugfix candidate.
This was doing extremely timid over-allocation, just rounding up to the
nearest multiple of 3. Now so long as the number of children is <= 128,
it rounds up to a multiple of 4 but via a much faster method. When the
number of children exceeds 128, though, and more space is needed, it
doubles the capacity. This is aggressive over-allocation.
SF patch <http://www.python.org/sf/578297> has Andrew MacIntyre using
PyMalloc in the parser to overcome platform malloc problems in
test_longexp on OS/2 EMX. Jack Jansen notes there that it didn't help
him on the Mac, because the Mac has problems with frequent ever-growing
reallocs, not just with gazillions of teensy mallocs. Win98 has no
visible problems with test_longexp, but I tried boosting the test-case
size and soon got "senseless" MemoryErrors out of it, and soon after
crashed the OS: as I've seen in many other contexts before, while the
Win98 realloc remains zippy in bad cases, it leads to extreme
fragmentation of user address space, to the point that the OS barfs.
I don't yet know whether this fixes Jack's Mac problems, but it does cure
Win98's problems when boosting the test case size. It also speeds
test_longexp in its unaltered state.
2002-07-08 03:32:09 -03:00
|
|
|
|
|
|
|
current_capacity = XXXROUNDUP(nch);
|
|
|
|
required_capacity = XXXROUNDUP(nch + 1);
|
2002-07-08 16:11:07 -03:00
|
|
|
if (current_capacity < 0 || required_capacity < 0)
|
|
|
|
return E_OVERFLOW;
|
PyNode_AddChild(): Do aggressive over-allocation when the number of
children gets large, to avoid severe platform realloc() degeneration
in extreme cases (like test_longexp).
Bugfix candidate.
This was doing extremely timid over-allocation, just rounding up to the
nearest multiple of 3. Now so long as the number of children is <= 128,
it rounds up to a multiple of 4 but via a much faster method. When the
number of children exceeds 128, though, and more space is needed, it
doubles the capacity. This is aggressive over-allocation.
SF patch <http://www.python.org/sf/578297> has Andrew MacIntyre using
PyMalloc in the parser to overcome platform malloc problems in
test_longexp on OS/2 EMX. Jack Jansen notes there that it didn't help
him on the Mac, because the Mac has problems with frequent ever-growing
reallocs, not just with gazillions of teensy mallocs. Win98 has no
visible problems with test_longexp, but I tried boosting the test-case
size and soon got "senseless" MemoryErrors out of it, and soon after
crashed the OS: as I've seen in many other contexts before, while the
Win98 realloc remains zippy in bad cases, it leads to extreme
fragmentation of user address space, to the point that the OS barfs.
I don't yet know whether this fixes Jack's Mac problems, but it does cure
Win98's problems when boosting the test case size. It also speeds
test_longexp in its unaltered state.
2002-07-08 03:32:09 -03:00
|
|
|
if (current_capacity < required_capacity) {
|
2008-06-11 04:41:16 -03:00
|
|
|
if (required_capacity > PY_SIZE_MAX / sizeof(node)) {
|
|
|
|
return E_NOMEM;
|
|
|
|
}
|
1990-10-14 09:07:46 -03:00
|
|
|
n = n1->n_child;
|
2002-08-04 03:28:21 -03:00
|
|
|
n = (node *) PyObject_REALLOC(n,
|
|
|
|
required_capacity * sizeof(node));
|
1990-10-14 09:07:46 -03:00
|
|
|
if (n == NULL)
|
2000-06-20 16:10:44 -03:00
|
|
|
return E_NOMEM;
|
1990-10-14 09:07:46 -03:00
|
|
|
n1->n_child = n;
|
|
|
|
}
|
PyNode_AddChild(): Do aggressive over-allocation when the number of
children gets large, to avoid severe platform realloc() degeneration
in extreme cases (like test_longexp).
Bugfix candidate.
This was doing extremely timid over-allocation, just rounding up to the
nearest multiple of 3. Now so long as the number of children is <= 128,
it rounds up to a multiple of 4 but via a much faster method. When the
number of children exceeds 128, though, and more space is needed, it
doubles the capacity. This is aggressive over-allocation.
SF patch <http://www.python.org/sf/578297> has Andrew MacIntyre using
PyMalloc in the parser to overcome platform malloc problems in
test_longexp on OS/2 EMX. Jack Jansen notes there that it didn't help
him on the Mac, because the Mac has problems with frequent ever-growing
reallocs, not just with gazillions of teensy mallocs. Win98 has no
visible problems with test_longexp, but I tried boosting the test-case
size and soon got "senseless" MemoryErrors out of it, and soon after
crashed the OS: as I've seen in many other contexts before, while the
Win98 realloc remains zippy in bad cases, it leads to extreme
fragmentation of user address space, to the point that the OS barfs.
I don't yet know whether this fixes Jack's Mac problems, but it does cure
Win98's problems when boosting the test case size. It also speeds
test_longexp in its unaltered state.
2002-07-08 03:32:09 -03:00
|
|
|
|
1990-10-14 09:07:46 -03:00
|
|
|
n = &n1->n_child[n1->n_nchildren++];
|
|
|
|
n->n_type = type;
|
|
|
|
n->n_str = str;
|
1990-12-20 11:06:42 -04:00
|
|
|
n->n_lineno = lineno;
|
2006-03-01 18:49:05 -04:00
|
|
|
n->n_col_offset = col_offset;
|
1990-10-14 09:07:46 -03:00
|
|
|
n->n_nchildren = 0;
|
|
|
|
n->n_child = NULL;
|
2000-06-20 16:10:44 -03:00
|
|
|
return 0;
|
1990-10-14 09:07:46 -03:00
|
|
|
}
|
1990-11-18 13:37:06 -04:00
|
|
|
|
1990-12-20 11:06:42 -04:00
|
|
|
/* Forward */
|
2000-07-09 00:09:57 -03:00
|
|
|
static void freechildren(node *);
|
1990-12-20 11:06:42 -04:00
|
|
|
|
|
|
|
|
|
|
|
void
|
2000-07-22 16:20:54 -03:00
|
|
|
PyNode_Free(node *n)
|
1990-12-20 11:06:42 -04:00
|
|
|
{
|
|
|
|
if (n != NULL) {
|
|
|
|
freechildren(n);
|
2002-08-04 03:28:21 -03:00
|
|
|
PyObject_FREE(n);
|
1990-12-20 11:06:42 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
1990-11-18 13:37:06 -04:00
|
|
|
static void
|
2000-07-22 16:20:54 -03:00
|
|
|
freechildren(node *n)
|
1990-11-18 13:37:06 -04:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
for (i = NCH(n); --i >= 0; )
|
|
|
|
freechildren(CHILD(n, i));
|
|
|
|
if (n->n_child != NULL)
|
2002-08-04 03:28:21 -03:00
|
|
|
PyObject_FREE(n->n_child);
|
1990-11-18 13:37:06 -04:00
|
|
|
if (STR(n) != NULL)
|
2002-08-04 03:28:21 -03:00
|
|
|
PyObject_FREE(STR(n));
|
1990-11-18 13:37:06 -04:00
|
|
|
}
|