Почему в виртуальной машине Java нет GIL? Почему Python так нужен?

Question

Я надеюсь, что кто-то может дать некоторое представление о том, что принципиально отличается от виртуальной машины Java, что позволяет ей красиво реализовывать потоки без необходимости в глобальной блокировке интерпретатора (GIL), в то время как Python требует такого зла.

Answer 1

Python (язык) не нуждается в GIL (именно поэтому он может быть идеально реализован на JVM [Jython] и .NET [IronPython], и эти реализации могут быть многопоточными свободно). CPython (популярная реализация) всегда использовал GIL для простоты кодирования (особенно кодирование механизмов сборки мусора) и интеграции не поточно-безопасных C-кодированных библиотек (раньше их было множество; -.)

Проект Unladen Swallow , помимо других амбициозных целей, планирует виртуальную машину без GIL для Python - цитируя этот сайт: «Кроме того, мы намерены удалить GIL и исправление состояния многопоточности в Python. Мы считаем, что это возможно благодаря внедрению более сложной системы GC, чем-то вроде IBM Recycler (Bacon et al, 2001). "

Answer 2

JVM (по крайней мере, горячая точка) имеет концепцию, аналогичную "GIL", она просто намного более тонка в своей детализации блокировки, большая часть этого происходит от GC в горячей точке, которые являются более продвинутыми.

В CPython это одна большая блокировка (вероятно, это не так, но достаточно хорошо для аргументов), в JVM она более распространена с различными концепциями в зависимости от того, где она используется.

Взгляните, например, на vm / runtime / safepoint.hpp в коде горячей точки, который фактически является барьером. Как только в безопасном месте вся виртуальная машина остановилась в отношении кода Java, так же, как виртуальная машина Python останавливается на GIL.

В мире Java такие события приостановки виртуальной машины известны как «остановка мира», в эти моменты только нативный код, связанный с определенными критериями, работает свободно, остальная часть виртуальной машины была остановлена.

Также отсутствие грубой блокировки в java делает JNI намного более трудным для написания, так как JVM дает меньше гарантий относительно своей среды для вызовов FFI, одна из вещей, которую cpython делает довольно простой (хотя и не такой простой, как использование ctypes). ).

Answer 3

Ниже в этом сообщении блога есть комментарий http://www.grouplens.org/node/244, который намекает на причину, по которой было так легко обойтись без GIL для IronPython или Jython, а именно то, что CPython использует подсчет ссылок, тогда как другие 2 виртуальные машины есть сборщики мусора.

Точная механика того, почему это так, я не понимаю, но это звучит как правдоподобная причина.

Answer 4

В этой ссылке они имеют следующее объяснение:

... "Части Интерпретатора не являются поточно-ориентированными, хотя в основном потому, что превращение их в многопоточные благодаря использованию массивных блокировок чрезвычайно замедляет однопоточность ( source ). Это, похоже, связано с Сборщик мусора в CPython, использующий подсчет ссылок (JVM и CLR этого не делают, и поэтому не нужно каждый раз блокировать / освобождать счетчик ссылок). Но даже если кто-то придумал приемлемое решение и внедрил его, сторонние библиотеки все равно будут есть те же проблемы. "

Answer 5

В Python отсутствует jit / aot, и временные рамки, в которых он был написан на многопоточных процессорах, не существовали. В качестве альтернативы вы можете перекомпилировать все в Julia lang, в котором отсутствует GIL, и получить некоторое ускорение в своем коде Python. Также Jython отстой, он медленнее, чем Cpython и Java. Если вы хотите придерживаться Python и подумать об использовании параллельных плагинов, вы не получите мгновенного прироста скорости, но вы можете выполнять параллельное программирование с правильным плагином.