Java仮想マシンにGILがないのはなぜですか？なぜPythonはそんなに悪いのが必要なのですか？

Pythonがそのような悪を必要とする一方で、グローバルインタープリターロック（GIL）を必要とせずにスレッドを適切に実装できるJava仮想マシンの根本的な違いについて誰かが洞察を提供できることを願っています。

Python（言語）はGILを必要としません（そのため、JVM [Jython]と.NET [IronPython]に完全に実装でき、これらの実装は自由にマルチスレッド化できます）。CPython（人気のある実装）は、コーディング（特にガベージコレクションメカニズムのコーディング）と非スレッドセーフなCコードライブラリの統合（これまで大量に使用されていた）を容易にするために、常にGILを使用してきました。 -）。

空車ツバメの他の野心的な目標の中でプロジェクトは、、ない計画 Python用GILのない仮想マシン-そのサイトを引用するには、「また、私たちはGILを削除して、Pythonでマルチスレッドの状態を固定しようとする私たちは、これがあると信じています。 IBMのリサイクラーのような、より洗練されたGCシステムの実装によって可能になります（Bacon et al、2001）。」

JVM（少なくともホットスポット）には「GIL」と同様の概念があります。ロックの細分度ははるかに細かく、そのほとんどは、より高度なホットスポット内のGCに由来しています。

CPythonでは、これは1つの大きなロックです（おそらく真実ではありませんが、議論のためには十分です）。JVMでは、それが使用される場所に応じて、さまざまな概念でさらに広がっています。

たとえば、ホットスポットコードのvm / runtime / safepoint.hppを見てください。これは事実上バリアです。セーフポイントになると、Python VMがGILで停止するように、Javaコードに関してVM全体が停止します。

Javaの世界では、このようなVMの一時停止イベントは「stop-the-world」として知られています。これらの時点では、特定の基準にバインドされたネイティブコードのみがフリーランニングであり、残りのVMは停止しています。

また、Javaには粗いロックがないため、JNIはFFI呼び出しの環境についての保証が少なくなるため、JNIの記述がはるかに難しくなります。

このブログの投稿http://www.grouplens.org/node/244の下に、IronPythonまたはJythonのGILが非常に簡単に省略できる理由を示唆するコメントがあります。CPythonは参照カウントを使用しますが、他の2つのVMにはガベージコレクタがあります。

これがなぜそうなのかについての正確なメカニズムは理解できませんが、もっともらしい理由のように聞こえます。

このリンクには、次の説明があります。

...「インタープリタの一部はスレッドセーフではありませんが、大規模なロックの使用によりすべてをスレッドセーフにすると、シングルスレッドが極端に遅くなるためです（ソース）。これは、参照カウントを使用するCPythonガベージコレクタ（JVMに関連しているようです） CLRはそうではないので、参照カウントを毎回ロック/リリースする必要はありません。しかし、誰かが受け入れ可能な解決策を考えて実装したとしても、サードパーティのライブラリは同じ問題を抱えています。」

Pythonにはjit / aotがなく、マルチスレッドプロセッサで記述されたタイムフレームは存在しませんでした。あるいは、GILが不足しているJulia langですべてを再コンパイルして、Pythonコードの速度を向上させることもできます。また、JythonはCpythonやJavaよりも遅いです。Pythonを使い続けたい場合は、並列プラグインの使用を検討してください。即座に速度が向上するわけではありませんが、適切なプラグインを使用して並列プログラミングを実行できます。