Re: [Python-Dev] Quick-and-dirty weak references

The one thing I'm not thrilled by in mxProxy is that a call to CheckWeakReferences() is needed before an object is cleaned up. I guess this boils down to the same problem I had with my weak reference scheme: you somehow want the Python core to tell the proxy stuff that the object can be cleaned up (although the details are different: in my scheme this would be triggered by refcount==0 and in mxProxy by refcount==1). And because objects are created and destroyed in Python at a tremendous rate you don't want to do this call for every object, only if you have a hint that the object has a weak reference (or a proxy). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

Jack Jansen wrote:
Well, the check is done prior to every action using a proxy to the object and also when a proxy to it is deallocated. The addition checkweakrefs() API is only included to enable additional explicit checking of the whole weak refs dictionary, e.g. every 10 seconds or so (just like you would with a mark&sweep GC). But yes, GC of the phantom object is delayed a bit depending on how you set up the proxies. Still, I think most usages won't have this problem, since the proxies themselves are usually temporary objects. It may sometimes even make sense to have the phantom object around as long as possible, e.g. to implement the soft references Tim quoted from the Java paper. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 135 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

In reply to no one in particular: I've often wished that the instance type object had an (optimized) __decref__ slot. With nothing but hand-waving to support it, I'll claim that would enable all these games. - Gordon

Without context, I don't know when this would be called. If you want this called on all DECREFs (regardless of the refcount value), realize that this is a huge slowdown because it would mean the DECREF macro has to inspect the type object, which means several indirections. This would slow down *every* DECREF operation, not just those on instances with a __decref__ slot, because the DECREF macro doesn't know the type of the object! --Guido van Rossum (home page: http://www.python.org/~guido/)

[me]
[Guido]
This was more 2.0-ish speculation, and really thinking of classic C++ ref counting where decref would be a function call, not a macro. Still a slowdown, of course, but not quite so massive. The upside is opening up all kinds of tricks at the type object and user class levels, (such as weak refs and copy on write etc). Worth it? I'd think so, but I'm not a speed demon. - Gordon

Jack Jansen wrote:
Well, the check is done prior to every action using a proxy to the object and also when a proxy to it is deallocated. The addition checkweakrefs() API is only included to enable additional explicit checking of the whole weak refs dictionary, e.g. every 10 seconds or so (just like you would with a mark&sweep GC). But yes, GC of the phantom object is delayed a bit depending on how you set up the proxies. Still, I think most usages won't have this problem, since the proxies themselves are usually temporary objects. It may sometimes even make sense to have the phantom object around as long as possible, e.g. to implement the soft references Tim quoted from the Java paper. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 135 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

In reply to no one in particular: I've often wished that the instance type object had an (optimized) __decref__ slot. With nothing but hand-waving to support it, I'll claim that would enable all these games. - Gordon

Without context, I don't know when this would be called. If you want this called on all DECREFs (regardless of the refcount value), realize that this is a huge slowdown because it would mean the DECREF macro has to inspect the type object, which means several indirections. This would slow down *every* DECREF operation, not just those on instances with a __decref__ slot, because the DECREF macro doesn't know the type of the object! --Guido van Rossum (home page: http://www.python.org/~guido/)

[me]
[Guido]
This was more 2.0-ish speculation, and really thinking of classic C++ ref counting where decref would be a function call, not a macro. Still a slowdown, of course, but not quite so massive. The upside is opening up all kinds of tricks at the type object and user class levels, (such as weak refs and copy on write etc). Worth it? I'd think so, but I'm not a speed demon. - Gordon
participants (4)
-
Gordon McMillan
-
Guido van Rossum
-
Jack Jansen
-
M.-A. Lemburg