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

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 t开发者_JAVA技巧hough there is discussion about the garbage collector interspersed with this talk about the GIL. Could someone explain the relation to me?

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.

Tuna-Fish's answer basically covers it. If you want more details, there was a discussion about how the GIL could be removed without having too much of an effect on the reference counting here: http://mail.python.org/pipermail/python-ideas/2009-October/006264.html

I just found another point of view on this subject here: http://renesd.blogspot.com/2009/12/python-gil-unladen-swallow-reference.html