Warum gibt es keine GIL in der Java Virtual Machine? Warum braucht Python so dringend einen?

Lesezeit: 4 Minuten

Ich hoffe, jemand kann einen Einblick geben, was grundlegend anders an der Java Virtual Machine ist, die es ihr ermöglicht, Threads gut zu implementieren, ohne dass ein Global Interpreter Lock (GIL) erforderlich ist, während Python ein solches Übel erfordert.

Python (die Sprache) benötigt keine GIL (weshalb sie perfekt auf JVM implementiert werden kann [Jython] und .NET [IronPython], und diese Implementierungen sind frei multithreadfähig). CPython (die beliebte Implementierung) hat immer eine GIL verwendet, um die Codierung (insbesondere die Codierung der Garbage-Collection-Mechanismen) und die Integration nicht-threadsicherer C-codierter Bibliotheken zu vereinfachen (davon gab es früher eine Menge; -).

Das Unbeladene Schwalbe Projekt, neben anderen ehrgeizigen Zielen, tut planen eine GIL-freie virtuelle Maschine für Python – um diese Seite zu zitieren: „Außerdem beabsichtigen wir, die GIL zu entfernen und den Zustand des Multithreading in Python zu reparieren wie IBMs Recycler (Bacon et al, 2001).”

  • Alex, was ist mit den alten Versuchen, die GIL zu entfernen, gab es nicht eine Menge Overhead damit (ein Faktor von 2 ist, woran ich mich erinnere)?

    – Bartosz Radaczyński

    15. Juli 2009 um 13:57 Uhr

  • Ja, Bartosz, Greg Stein hat das 1999 gemessen. Garbage Collection by Reference Counting war der Killer, der einen enormen Aufwand für feinkörniges Sperren erzwang. Deshalb ist dort ein fortschrittlicherer GC entscheidend.

    – Alex Martelli

    15. Juli 2009 um 16:19 Uhr

  • Das Team von Unladen Swallow hat es aufgegeben, die GIL zu entfernen: code.google.com/p/unladen-swallow/wiki/…

    – Seun Osewa

    20. März 2010 um 20:25 Uhr

  • Alternativen zu Unladen und CPython sind PyPy, Jython und IronPython. Die letzteren beiden haben keine GIL, aber die Verwendung des Multiprocessing-Moduls umgeht die GIL und ist sowieso sicherer.

    – Cees Timmermann

    12. März 2012 um 11:30 Uhr

Benutzer-Avatar
Greg Bowyer

Die JVM (zumindest Hotspot) hat ein ähnliches Konzept wie die “GIL”, sie ist nur viel feiner in ihrer Lock-Granularität, das meiste davon kommt von den GCs im Hotspot, die weiter fortgeschritten sind.

In CPython ist es eine große Sperre (wahrscheinlich nicht so wahr, aber gut genug für Argumente), in der JVM ist es mehr verbreitet mit unterschiedlichen Konzepten, je nachdem, wo es verwendet wird.

Schauen Sie sich zum Beispiel vm/runtime/safepoint.hpp im Hotspot-Code an, was effektiv eine Barriere darstellt. An einem Sicherungspunkt hat die gesamte VM in Bezug auf Java-Code angehalten, ähnlich wie die Python-VM an der GIL anhält.

In der Java-Welt werden solche VM-Pause-Ereignisse als „Stop-the-World“ bezeichnet, an diesen Stellen läuft nur nativer Code, der an bestimmte Kriterien gebunden ist, frei, der Rest der VM wurde gestoppt.

Auch macht das Fehlen einer groben Sperre in Java das Schreiben von JNI viel schwieriger, da die JVM weniger Garantien für ihre Umgebung für FFI-Aufrufe gibt, eines der Dinge, die cpython ziemlich einfach macht (wenn auch nicht so einfach wie die Verwendung von ctypes).

Es gibt einen Kommentar unten in diesem Blogbeitrag http://www.grouplens.org/node/244 Das deutet auf den Grund hin, warum es so einfach war, auf eine GIL für IronPython oder Jython zu verzichten, nämlich dass CPython die Referenzzählung verwendet, während die anderen 2 VMs Garbage Collectors haben.

Die genaue Mechanik, warum das so ist, verstehe ich nicht, aber es klingt nach einem plausiblen Grund.

  • Wenn Sie Objekte promiskuitiv zwischen Threads austauschen, ist es etwas umständlich herauszufinden, wann niemand mehr einen Verweis auf ein bestimmtes Objekt hat. Das Referenzzählen mit einer globalen Sperre ist eine (teure) Möglichkeit. Ein anderer Lösungsweg wäre gewesen, nur jeweils einen Thread Verweise auf das Objekt enthalten zu lassen, wodurch die meisten Aktivitäten Thread-lokal wären, auf Kosten der Kommunikation zwischen den Threads. Persönlich denke ich, dass es aufschlussreich ist, dass HPC die Nachrichtenübermittlung zwischen Prozessoren und nicht den gemeinsamen Speicher verwendet, und dass dies aus Gründen der Skalierbarkeit geschieht …

    – Donal Fellows

    12. April 2010 um 22:03 Uhr

  • Hm, nun, im Grunde gibt es zwei Arten von Garbage Collection: Mark and Sweep (oder Stop-and-Cioy, oder wie auch immer Ihre spezielle Implementierung dieses Ansatzes genannt wird) und Ref Counting. Die JVM verwendet derzeit eine Kombination aus beiden IMHO (Generational Garbage Collection). Java sollte also unter den gleichen Problemen mit der Synchronisierung von Ref-Zählern leiden wie Python?

    – Michael Bier

    29. April 2021 um 18:57 Uhr


In diesem Verknüpfung Sie haben die folgende Erklärung:

… “Teile des Interpreters sind nicht Thread-sicher, obwohl hauptsächlich deshalb, weil es Single-Threading extrem verlangsamen würde, wenn sie alle durch massive Verwendung von Sperren Thread-sicher gemacht würden (Quelle). Dies scheint mit dem CPython-Garbage Collector zusammenzuhängen, der die Referenzzählung verwendet (JVM und CLR tun dies nicht und müssen daher nicht jedes Mal eine Referenzzählung sperren/freigeben). Aber selbst wenn jemand an eine akzeptable Lösung denken und sie implementieren würde, hätten Bibliotheken von Drittanbietern immer noch die gleichen Probleme.”

Python fehlt jit/aot und der Zeitrahmen, in dem es auf Multithread-Prozessoren geschrieben wurde, existierte nicht. Alternativ könnten Sie alles in Julia lang neu kompilieren, dem GIL fehlt, und Ihren Python-Code etwas schneller machen. Außerdem ist Jython irgendwie beschissen, es ist langsamer als Cpython und Java. Wenn Sie bei Python bleiben möchten, sollten Sie parallele Plugins verwenden. Sie erhalten keinen sofortigen Geschwindigkeitsschub, aber Sie können mit dem richtigen Plugin parallel programmieren.

  • Was ist mit PyPy?

    – denis631

    22. Januar 2019 um 12:30 Uhr

  • Was ist mit PyPy?

    – denis631

    22. Januar 2019 um 12:30 Uhr

1351160cookie-checkWarum gibt es keine GIL in der Java Virtual Machine? Warum braucht Python so dringend einen?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy