Нашлась ещё одна статья, которая популярно обьясняет суть предложенных изменений. А я попытаюсь пересказать своими словами.

Короче, самой большой проблемой при удалении GIL является сборщик мусора CPython, работающий по принципу счетчика ссылок. Важно, чтобы операции инкремента и декремента счетчика ссылок были атомарными, иначе сборщик мусора может либо удалить ещё используемый объект (и это будет segfault), либо пропустить уже неиспользуемый (утечки памяти). Если просто в тупую защитить операции со счетчиком ссылок при помощи какого-нибудь лока, то производительность интерпретатора сразу же сильно падает, потому что эти операции происходят очень-очень часто. Поэтому нужны более хитрые подходы. Автор предложения придумал три вещи (или скорее не придумал, а вдохновился в других языках).

1. Сделать два счетчика ссылок. Один (не атомарный, быстрый) будет считать количество ссылок внутри потока-владельца, который создал объект, а другой (атомарный, медленный) — количество ссылок во всех остальных потоках. Пока в главном потоке есть ссылки на объект, можно даже не проверять второй счётчик, потому что объект точно нельзя удалять. Когда в главном потоке больше не остаётся ссылок, а в других потоках они ещё есть, то сборщик мусора ориентируется на второй, медленный счётчик ссылок. Эта оптимизация основана на предположении, что большинство объектов используются лишь в рамках одного потока. Это то самое, что защищает однопоточные программы от большой просадки по производительности.

2. Объекты-синглтоны (None, True, False, Ellipsis), а также некоторые числа и строки, бессмертны, они остаются в памяти навсегда. Эти объекты используются практически повсеместно. Тем не менее, в нынешней реализации для них ведётся подсчёт ссылок, что является бессмысленной работой. Вот, предлагается не делать этого. Такие объекты будут помечаться специальным флажком, чтобы сборщик мусора даже не смотрел в их сторону, и подсчёт ссылок для них тоже не будет вестись.

3. Объекты модулей и функций не бессмертны, но они как минимум живут долго. Зачастую они ссылаются друг на друга, образуя циклы, так что счётчики ссылок все равно не помогут понять, когда они перестанут использоваться. Я не совсем понял суть, но кажется, что можно тоже упразднить подсчёт ссылок для таких объектов, и доверить очистку более мудрому и медленному сборщику мусора, который просыпается время от времени, останавливает мир и отлавливает объекты с циклическими ссылками. Это уже реализовано в CPython, если что.

Также были переработаны имплементации списков и словарей, а механизм аллокации памяти был заменён на другой, который лучше работает с многопоточными программами.

Ещё автор применил и другие оптимизации, наверное, чтобы его предложение не было сразу же зарублено на корню, потому что оно все-таки слегка замедляет однопоточный кейс. Скорее всего, эти оптимизации в любом случае попадут в CPython, даже если работу, связанную с GIL, отклонят.

Некоторые бенчмарки показывают ускорение в 18-20 раз при 20 потоках, по сравнению с однопоточным исполнением, то есть Python действительно эффективно утилизирует разные ядра.

https://lwn.net/SubscriberLink/872869/0e62bba2db51ec7a/

#gil #конспект