[Patches] [ python-Patches-421893 ] Cleanup GC API
noreply@sourceforge.net
noreply@sourceforge.net
Wed, 29 Aug 2001 17:22:39 -0700
Patches item #421893, was opened at 2001-05-06 14:42
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421893&group_id=5470
Category: core (C code)
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Neil Schemenauer (nascheme)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Cleanup GC API
Initial Comment:
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.
----------------------------------------------------------------------
>Comment By: Neil Schemenauer (nascheme)
Date: 2001-08-29 17:22
Message:
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?
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-08-29 15:21
Message:
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).
----------------------------------------------------------------------
Comment By: Neil Schemenauer (nascheme)
Date: 2001-08-29 10:47
Message:
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.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-08-22 14:28
Message:
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.
----------------------------------------------------------------------
Comment By: Neil Schemenauer (nascheme)
Date: 2001-08-19 12:59
Message:
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.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-09 09:32
Message:
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.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-06-16 09:25
Message:
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.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-06-04 10:13
Message:
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.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=421893&group_id=5470