私はちょうどPythonを学び始めたばかりで、GILとそれがどのように「本当の」マルチスレッドを妨げるのか聞いたことがあります（これは、複数のスレッドが同時に異なるコアで動作することを可能にします）。VMはそのスレッドにスレッドごとに複数のインスタンスを必要としますか？
ここで、GILを削除すると、別のコアで実行されている各スレッドは、実行するためにVMの別のインスタンスを必要としないのですか？ JVMにも同じ問題がありますか？
もしそうなら、VM上で解釈され/実行されるプログラムに対してスレッドを使用することには利点がありますか？（POSIXスレッド対プロセスのパフォーマンスの向上とは別に - すごいね）？スレッドごとにVMのインスタンスを個別に持つ必要があるため、オーバーヘッドのように見えます。
ありがとうございました。
いいえ、VMの別個の「インスタンス」は必要ありません。なぜそこにあるのだろうか？ GILの問題は、すべてのスレッド間で共有する必要がある1つのデータ構造であり、ロックなしで複数のスレッドから安全にアクセスできないことです。基本的には解決策はそのようなことを避けることです：
スレッドごとまたはコアごとのデータ構造（たとえば、いくつかのJVMはスレッドローカルヒープからメモリを割り当てることができます。割り当ては本当に速いですが）それはスレッドまたはコアごとに別個のVMインスタンス全体と同じではありません。
GILの問題は単なる粒度の1つです。 GILは、Pythonインタプリタのすべてのデータ構造を保護するグローバルロックです。解決策は、同じデータ構造を保護するために細かいロックを使用することです。
状況は、SMPを有効にするために2.0で導入されたLinuxカーネルBKL（Big Kernel Lock）の状況に似ています。 BKLは徐々に細かいロックに取って代わられ、つい最近ではなくなってしまった（2.6.39？）。
ご返信ありがとうございます。実際には各スレッドで実行されているPython/Javaコードを実行するためには、各スレッドごとに別々のVMインスタンスが必要であると思っていました（マシンコードではないので、VMと複数の命令 –
@Arash：まあ、PythonはJavaよりもダイナミックであるためにかなり多くの作業をしています。たとえJavaがまだ厳密に解釈されていても、その解釈は複数のスレッドで発生する可能性があります。しかし、ほとんどの場合、ほとんどのJavaコードは実際には* JITコンパイルされたバイトコードから直接マシンコードを実行しています。 –
したがって、すべての解釈を行っているVMコード自体がマルチスレッド化される可能性があるため、VMによって実行される異なるスレッドで実行されているコードは、実際のVMを実行する異なるスレッドによって実行されています。 –