Issue421893
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.
Created on 2001-05-06 21:42 by nascheme, last changed 2022-04-10 16:04 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
gc_docs.diff | nascheme, 2001-08-30 00:22 |
Messages (10) | |||
---|---|---|---|
msg36516 - (view) | Author: Neil Schemenauer (nascheme) * | Date: 2001-05-06 21:42 | |
This patch adds three new APIs: PyObject_GC_New PyObject_GC_NewVar PyObject_GC_Resize PyObject_GC_Del and renames PyObject_GC_Init and PyObject_GC_Fini to: PyObject_GC_Track PyObject_GC_Ignore respectively. Objects that wish to be tracked by the collector must use these new APIs. Many more details about the GC implementation are hidden inside gcmodule.c. There seems to be no change in performance. Note that PyObject_GC_{New,NewVar} automatically adds the object to the GC lists. There is no need to call PyObject_GC_Track. PyObject_GC_Del automatically removes the object from the GC list but usually you want to call PyObject_GC_Ignore yourself (DECREFs can end up running arbitrary code). It should be more difficult to corrupt the GC linked lists now. Also, you can now call PyObject_GC_Ignore on objects that you know will not create RCs. The _weakref module does this. Previously, every object that had the GC type flag set and could be found by using tp_traverse had to be in a GC linked list. |
|||
msg36517 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2001-06-04 17:13 | |
Logged In: YES user_id=21627 I have two problems with this patch: 1. It comes with no documentation. 2. It breaks existing third-party modules which use the GC API as defined in Python 2. Consequently, I recommend rejection of the patch in its current form. |
|||
msg36518 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2001-06-16 16:25 | |
Logged In: YES user_id=6380 I think I know a way to fix the incompatibility, by switching to a different flag bit. I'll try to work this into the descr-branch code. |
|||
msg36519 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2001-08-09 16:32 | |
Logged In: YES user_id=6380 Neil, do we still need this? I've marked it out-of-date because I'm sure that it won't apply cleanly any more. |
|||
msg36520 - (view) | Author: Neil Schemenauer (nascheme) * | Date: 2001-08-19 19:59 | |
Logged In: YES user_id=35752 I've brought the patch up to date. I'm not sure if we really need this patch. The current approach works okay. I think this patch improves things since more details about the GC implementation are hidden. This would give us more freedom to change the implementation in the future. Also, I think the patch makes it easier for extension types to support GC. The patch is somewhat backwards compatible now. Types that use the old interface will still compile but will not be GCed. |
|||
msg36521 - (view) | Author: Tim Peters (tim.peters) * | Date: 2001-08-22 21:28 | |
Logged In: YES user_id=31435 I want to see this patch go in: it affords some nice simplifications in many places, so should make the code easier to maintain and to change. Some gripes: + Most of the new functions don't appear to be documented at all, except in that they're mentioned in passing by the docs for other new functions: PyObject_GC_New, PyObject_GC_NewVar, PyObject_GC_Resize, PyObject_GC_Del. + Unlike the old Init/Fini, the new Track/Ignore don't "sound like" matching brackets. TrackOn/TrackOff, TrackStart/TrackStop, Track/UnTrack, ... would be better for this reason. I draw the line at PyObject_GC_New vs PyObject_GC_Old, though <wink>. + Overall, and despite the pain it causes, it's probably better to let GC continue to get triggered by "deallocation deficit", rather than moving the prod into the eval loop. Guido says you two already discussed that, so I won't belabor it here. I'll note that one consequence of the current policy is that GC glitches got triggered during compilation, and mysterious as those were, that they *did* happen during compilation allowed to rule out huge pieces of the Python runtime code; it was significantly harder to pin the blame for glitches that didn't happen until runtime. |
|||
msg36522 - (view) | Author: Neil Schemenauer (nascheme) * | Date: 2001-08-29 17:47 | |
Logged In: YES user_id=35752 Changes in this version: * Rename PyObject_GC_Ignore to PyObject_GC_UnTrack. * Documention new functions * Revert collection from inside ceval change. * Add TRACK/UNTRACK macros (should not be used by extensions otherwise modules compiled with a different WITH_CYCLE_GC setting will break). Are the TRACK/UNTRACK macros a good idea? I think they give a measurable speed increase. |
|||
msg36523 - (view) | Author: Tim Peters (tim.peters) * | Date: 2001-08-29 22:21 | |
Logged In: YES user_id=31435 Accepted, and back to Neil for checkin. I don't think you need to go thru Guido again, as you and I both talked with him about the issues, and you've addressed them. Feel free to reassign to Fred if you want better doc review, though. I don't know what to make of someone "thinking" a speed increase is measurable: you either measured one, or you didn't <wink>. My intuition is that the macros are a good idea, although if they're not to be used by extension modules then their names should begin with an underscore (to make clear that they're not part of the public API). |
|||
msg36524 - (view) | Author: Neil Schemenauer (nascheme) * | Date: 2001-08-30 00:22 | |
Logged In: YES user_id=35752 Everything checked in except the doc changes. Fred, can you take a look and check them in if they are okay? |
|||
msg36525 - (view) | Author: Fred Drake (fdrake) | Date: 2001-08-30 03:04 | |
Logged In: YES user_id=3066 The contents of the \cfunction macro should always include the trailing "()" after the name of the function; there are at least two cases where it is missing. Otherwise, this looks good; make that change and check it in, then close the patch. Thanks! |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:04:02 | admin | set | github: 34463 |
2001-05-06 21:42:31 | nascheme | create |