Movatterモバイル変換
[0]ホーム
A couple garbage collector questions
Hannah Schroeterhannah at schlund.de
Wed Apr 25 13:06:58 EDT 2001
Hello!In article <mailman.987747988.15494.python-list at python.org>,Daniel Berlin <dan at www.cgsoftware.com> wrote:>[...]>As for data on the other side, i've never seen non-atomic reference>counting exact a huge performance penalty, in a well-designed application.>INCREF is a macro that expands to (with depythonified equivalent names) :>object->refcount++.>DECREF is a macro that expands to (with depythonified equivalent names):>if (object->refcount--) free(object)And in a threaded environment, that is in fact:INCREF ->lock(refcnt_mutex)object->refcount++unlock(refcnt_mutex)DECREF ->lock(refcnt_mutex)object->refcount--if (! object->refcount)free(object)unlock(refcnt_mutex)The refcnt_mutex can either be global (much contention) or per refcnt(memory overhead for lock datastructure in addition to the refcntitself). Or it could be per ((size_t)object) >> A_FEW_BITS pages,or anything similar.>I'm pretty curious as to how you think this will exact a huge performance>cost.>Cache locality isn't hurt, why the heck would you decref an object you>hadn't just used? Why the heck would you incref an object you weren't>about to use?Objects you fill into collections/remove out of them? The actual referenceto the object instance data may be arbitrarily near/far away from the refcntoperations.>So where is the huge performance cost i'm paying?See, one assignmentx = yis in general in fact anif (x != nil)DECREF(x)if (y != nil)INCREF(y)x = ySo, expanded, that is:if (x != nil) {lock(x->refcnt_lock)x->refcnt --unlock(x->refcnt_lock)if (! x->refcnt)free(x)}if (y != nil) {lock(y->refcnt_lock)y->refcnt++unlock(y->refcnt_lock)}x = yOn real GC's, it is just:x = yNo lock overhead and potential lock contention, and even in the singlethreaded case (no locks), you still have a significant instruction overhead.Except if you achieve to eliminate most INCREF/DECREFs through intelligentglobal dataflow analysis.Kind regards,Hannah.
More information about the Python-listmailing list
[8]ページ先頭