What does Python's GIL have to do with the garbage collector?

Question

I just saw this section of Unladen Swallow's documentation come up on Hacker News. Basically, it's the Google engineers saying that they're not optimistic about removing the GIL. However, it seems as though there is discussion about the garbage collector interspersed with this talk about the GIL. Could someone explain the relation to me?

Answer 1

The really short version is that currently python manages memory with a reference counting+a mark&sweep cycle collector scheme, optimized for latency (instead of throughput).

This is all fine when there is only a single mutating thread, but in a multi-threaded system, you need to synchronize all the times you modify refcounts, or else you can have values "fall trough the cracks", and synchronization primitives are quite expensive on contemporary hardware.

If refcounts weren't changed so often, this wouldn't be a problem, but pretty much every single operation you do in cpython can cause a refcount to change somewhere, so the options are either GIL, doing refcounts with some kind of synchronization (and literally spend almost all your time on the synch), or ditch the refcounting system for some kind of a real garbage collector.