In today's CPython with the GIL, it's hard to beat the existing simple reference counting approach.  It's already so cheap, and CPython's implementation has had a lot of optimization.

I implemented "buffered reference counting" in the Gilectomy because it's far friendlier to multicore.  It added an enormous amount of overhead.  But with enough cores it would eventually become a performance win.

I'm not optimistic that coalescing would be a win for CPython.  On the C side, reference count change code is written by hand, so hopefully it already does an intelligent job without redundant reference changes.  On the bytecode side, reference count changes are implicit, so there's nothing you can optimize.  Changing CPython bytecode to make explicit reference count changes would add so much overhead--the generated bytecode would be much larger, you'd be dispatching so many reference count change opcodes--that it's hard to imagine it would be cheaper than just living with the redundant reference count changes.

My memory is hazy, but IIRC "deferred" reference counting is a clever scheme in which stack references don't change the reference count, only heap references do.  An object has to have a reference count of zero and have no active references in the stack in order to be collected.  This seems like a lovely idea, maximizing the best attributes of both reference counting and tracing garbage collection.   However, this would require walking the stack(s), which we can't do in cross-platform ANSI C.  It would also require a complete overhaul of the C code for CPython itself (and eventually all extensions), hand-reviewing every reference count change to decide "is this a heap or a stack reference"?

I don't think there is "low-hanging fruit" left to optimize in CPython's reference counting scheme.  So all that's left are major rewrites like "deferred" reference counting.  Personally I think the future of CPython is to change completely over to tracing garbage collection.  It's so much friendlier to multicore, which is clearly the future of programming.  I'd rather see efforts in this area directed towards that goal.


On 9/1/20 9:34 AM, Guido van Rossum wrote:
On Tue, Sep 1, 2020 at 9:25 AM Raihan Rasheed Apurbo <> wrote:
Before experimenting can't I ask someone whether relevant experiments were made or not?  if I am not supposed to do that then I totally agree with you, sir.

I tried asking in python-ideas and one of the replies was "I gather there have been some experiments along these lines as part
of efforts to remove the GIL. You might like to research them to find out how much success they've had."

What I can interpret from this reply is there are some experiments regarding this topic but I don't know where they are.  Then I asked him where could I find them but didn't get any answer to that.

Then how have I got my answers?

I am so sorry if I am asking any inappropriate question here.


Nobody knows the answers to your questions ("can we optimize...", "where would I face problems...", "is there something I am missing?", "tell me the factors I should consider").

Your questions are somehow presented as if we *should* know the answers, and seem to insinuate that we should have investigated the techniques you mention. The answer to this is that we are doubtful that it will be easy to implement them in a fully backwards compatible way (and you'd be surprised how important backwards compatibility is).

The only thing I personally know about this topic is that Larry Hastings attempted a more sophisticated approach to multi-threaded reference counting without the GIL, and came up short despite putting a lot of effort in it. You should probably do some Googling on Gilectomy and find Larry's various annual updates. That is presumably what that python-ideas answer was referring to.

Good luck.

--Guido van Rossum (

Python-Dev mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct: