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

Question

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

Answer 1

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

Тот самый Порожняя Ласточка проект, помимо других амбициозных целей, ставит план виртуальная машина без GIL для Python - цитирую этот сайт: "Кроме того, мы намерены удалить GIL и исправить состояние многопоточности в Python.Мы считаем, что это возможно благодаря внедрению более сложной системы сбора отходов, что-то вроде 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 использует подсчет ссылок, тогда как две другие виртуальные машины имеют сборщики мусора.

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

Answer 4

В этом связь у них есть следующее объяснение:

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

Answer 5

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