Repository navigation
Stop using the garbage collector to manage the lifetime of the getargs.c freelist #58533
Description
| BPO | 14325 |
|---|---|
| Nosy | @skrah |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2012-03-16.18:26:10.021>
created_at = <Date 2012-03-15.18:22:39.790>
labels = ['type-feature']
title = 'Stop using the garbage collector to manage the lifetime of the getargs.c freelist'
updated_at = <Date 2012-03-16.18:26:10.020>
user = 'https://bugs.python.org/exarkun'bugs.python.org fields:
activity = <Date 2012-03-16.18:26:10.020>
actor = 'python-dev'
assignee = 'exarkun'
closed = True
closed_date = <Date 2012-03-16.18:26:10.021>
closer = 'python-dev'
components = []
creation = <Date 2012-03-15.18:22:39.790>
creator = 'exarkun'
dependencies = []
files = ['24873', '24890']
hgrepos = []
issue_num = 14325
keywords = ['patch']
message_count = 7.0
messages = ['155926', '156020', '156022', '156024', '156057', '156058', '156067']
nosy_count = 4.0
nosy_names = ['exarkun', 'eli.bendersky', 'skrah', 'python-dev']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue14325'
versions = []
Activity
exarkun commentedon Mar 15, 2012
Allocating a Python list and a bunch of Capsules for each PyArg_ParseTuple call is expensive and unnecessarily complicated.
The freelist never escapes getargs.c (if it ever did, it would be a bug). The same job can be accomplished with a normal C array.
python-dev commentedon Mar 16, 2012
New changeset 9fc456ac20cf by Jean-Paul Calderone in branch 'default':
Issue bpo-14325: Stop using python lists, capsules, and the garbage collector to deal with PyArg_Parse* cleanup.
http://hg.python.org/cpython/rev/9fc456ac20cf
elibendersky commentedon Mar 16, 2012
This is cool! Any benchmark / speedup data?
exarkun commentedon Mar 16, 2012
If it's a bit faster, that'd be a nice win, but I didn't benchmark. I'm primarily interested in correctness in the PyPy case (PyPy re-uses this code), and I think CPython benefits from the slightly simplified code as well.
If you do any benchmarks, I'd love to hear the results, though. :)
skrah commentedon Mar 16, 2012
I'm getting a leak since this revision:
./configure --without-pymalloc CFLAGS="-O0 -g" && make
valgrind --db-attach=yes --suppressions=./Misc/valgrind-python.supp --leak-check=full ./python leak.py
==32303== 16 bytes in 1 blocks are definitely lost in loss record 3 of 2,489
==32303== at 0x4C27878: malloc (vg_replace_malloc.c:236)
==32303== by 0x41DDB0: PyMem_Malloc (object.c:1841)
==32303== by 0x4A72BF: vgetargskeywords (getargs.c:1432)
==32303== by 0x4A6E1C: PyArg_ParseTupleAndKeywords (getargs.c:1301)
==32303== by 0x55D1C8: float_new (floatobject.c:1557)
==32303== by 0x42B643: type_call (typeobject.c:708)
==32303== by 0x532A9F: PyObject_Call (abstract.c:2150)
==32303== by 0x491483: do_call (ceval.c:4260)
==32303== by 0x490A33: call_function (ceval.c:4063)
==32303== by 0x48BD49: PyEval_EvalFrameEx (ceval.c:2662)
==32303== by 0x48EA11: PyEval_EvalCodeEx (ceval.c:3414)
==32303== by 0x482FC6: PyEval_EvalCode (ceval.c:771)
skrah commentedon Mar 16, 2012
Here's leak.py.
python-dev commentedon Mar 16, 2012
New changeset d08f0f3ab23e by Benjamin Peterson in branch 'default':
plug memory leak (closes bpo-14325)
http://hg.python.org/cpython/rev/d08f0f3ab23e