Python 仮想マシン内を見て回ったところ、戻ってきたら殺されていました!

私は C ドライブの深いディレクトリで生まれましたが、誰が私をここに置いたのかはわかりません。

[[284293]]

何もすることがなく、一日中ただ寝ていました。目が覚めると、隣のAccount.classとチャットをしていました。彼はメモリ内の Java 仮想マシンに一度行ったことがあり、奇妙な警官、仮想マシンの建物、クリーナーなど、JVM での冒険を私に何度も繰り返し語りました。私はそんな冒険をしたくてうずうずしていました。

彼は私にこう言いました。「冒険は二人の警官から始まる。彼らが来るのを待つだけだ。」

奇妙な警官

ある日、私が寝ていると、突然誰かがドアを叩きました。

ドアを開けると、背の高い人と背の低い人の奇妙な警官が二人いました。私の冒険が始まろうとしていた。

「あなたはClassLoaderですか？」 Account.class には、ロードする ClassLoader という警官がいると書いてあったことを思い出しました。

「ClassLoader って何ですか? Python は Java のトリックを使わないんです!」凶暴な小柄な警官は、自分の仕事のIDを渡しました。「私はPythonコンパイラです。あなたの住所を調べるよう命じられました。隠しpycファイルはありますか？」

「pyc？何のpyc？」ストーリー展開がAccount.classの発言と明らかに矛盾しているように感じます。

「ふりはやめなさい！」彼は辺りを見回し、すぐに _pycache_ という隅から user.pyc というファイルを取り出しました。「隠しファイルがないなんて、どうして言えるんですか？」

本当にショックでした。確かに私はuser.pyでした。この pyc はいつここに隠されたのですか?

「確認してみましょう」と、Python コンパイラは虫眼鏡を取り出して、pyc のバイナリデータを調べ始めました。「そうですね、マジックナンバーは 3394 です。これは Python 3.7 でコンパイルされました。しかし、変更タイムスタンプから判断すると、古すぎます。」

Python コンパイラが話し終えるとすぐに、彼はピストルを取り出し、バンと音を立てて pyc を殺しました。彼は私のほうを向いて言いました。「それでは、再コンパイルします。」

かわいそうなピクシー、セリフも言わないうちに跡形もなく消えてしまった。

「order.py というファイルがインポートされました。メモリコンパイルに進むように指示されました。」 Python コンパイラは冷たく言った。

私は驚きました。「Python はインタープリタではないのですか? なぜコンパイルする必要があるのですか?」

「なんて無知なのでしょう。Python にはバイトコードを実行する仮想マシンがあります。最初にコンパイルされ、次に解釈されて実行されます。メモリコンパイルに進みましょう。」

二人の警官は私に何も持ち込むことを許可しなかったため、私を車に押し込み、一緒に思い出の場所に向かって走りました。

ニュースを入手

私の将来は不確実だと感じています。コンパイル後に強制終了するのでしょうか?ただ座って死を待つことはできません。もっと多くの情報を学ばなければなりません。

「警官さん、どうやって私を見つけたんですか？」私は背の高い警官に慎重に尋ねた。

背の高い警官はとても親切で、手にノートを振りながら言いました。「私は Python インタープリターです。ノートに記録されている Python モジュールの検索ルールに従って検索します。最初にプログラムが実行されている現在のディレクトリを調べ、次に PYTHONPATH を調べ、最後に Python のインストール設定に関連するデフォルトのパスを調べます。」

「見てください」と彼はノートブックを指差しながら言いました。「あなたは C:\users\andy\temp\python\ というディレクトリにいます。」

これは Java の ClassPath に似ていると思いました。

「なるほど、それではなぜあの警官は殺されたのですか？」私は緊張して、無意識のうちに車を運転している Python コンパイラーをちらっと見ました。

「一度コンパイルすると時間がかかるので、バイトコードは pyc ファイルにキャッシュされます。ソースコードが変更されていない場合は、次回コンパイルする必要はなく、直接実行できます。そうでない場合、pyc ファイルは役に立ちません。」

私は安堵のため息をついた。ソースコードが変更されたようです!

「ClassLoader を使わないのはなぜですか? Java ではこれができると聞きました。」

「長い話になるよ」背の高い警官は辛抱強く言った。「Java が最初に開発されたとき、インターネットからコードをダウンロードしてローカル JVM で実行できるという非常に先進的な概念がありました。しかし、インターネット上のコードが有害かどうかはどうやってわかるのでしょうか。そこでサンドボックスメカニズムが作成され、ClassLoader もレイヤーに分割されました。Java のコアクラス (java.lang.String など) は、最上位の ClassLoader によってのみロードできます。これは、悪意のある人が同じ名前のコアクラスを書いて損害を与えるのを防ぐためです。」

私はうなずきました。「ああ、Python にはそのような要件はありません。ソースファイルを取得してコンパイルし、解釈して実行します。複雑なクラスローダーは必要ありません。」

コンパイル

彼らが話している間に、車は思い出の中へと走り去っていった。

Python コンパイラが停止し、すべてのコードをメモリに移動します。次に、一連の見事な字句解析と言語解析を行って抽象構文木を形成し、抽象構文木からバイトコードを形成します。ここでは3,000語を省略します。

最後に、彼は私をメモリ内のバイナリバイトコードに変換しました。

「これは一体何だ？」

Python コンパイラは、「これは pyc、つまり PyCodeObject です。一度コンパイルするのは大変です。この PyCodeObject オブジェクトを pyc ファイルに保存します。そうすれば、次回はコンパイルする必要がなくなります。」と言います。

「例を挙げましょう」と背の高いPythonインタープリターは言いました。「user.pyにこのコードがあります

def を追加します(a,b):

c = a + b

印刷(c)

PyCodeObject にコンパイルすると、次のようになります。

(注: ここで示されているのはほんの一部であり、実際の PyCodeObject は複雑にネストされた構造になっていることが多いです)

ローカル定数テーブルには、ローカル変数 a、b、c が記録されます。

シンボルテーブルには、print など、プログラムによって参照されるシンボルが記録されます。

バイトコードは、定数テーブルとシンボルテーブルを参照する実際の命令です。 ”

ほんの一部を見せただけでもとても複雑です。そんなに細かいところまで見るのは面倒です。 Account.classのスクリプトに従って、次はメソッド領域に進んでいこうと思いました。

しかし、背の高い Python インタープリタはこう言いました。「ここにはメソッド領域はありません。Python オブジェクトとデータ構造はすべてヒープに格納されます。user.py、これがあなたのアドレスです。PyCodeObject をそこに持っていけば、すぐにスレッドがあなたに連絡します。」

埋め込む

ヒープ地区へ向かう途中、完全武装した兵士の一団が絶えず巡回し、時折何かを取り出して車に詰め込んでいるのが見えました。言うまでもなく、これらはひどいクリーナーでした。

よく見てみると、各オブジェクトの先頭に参照カウントがあることがわかりました。使用すればカウントは増加し、使用されなければカウントは減少します。ゼロになったら、残念ですが危険です。

私たちは住所に従って個室を見つけ、座った瞬間にテーブルの上のビデオ電話が鳴った。

写真では、明るい CPU ワークショップに 0x7954 という番号のスレッドが置かれていました。彼の目の前には、深いバケツ（後で知ったのですが、これはスタックと呼ばれていました）と小さなグリッドの列、そして「GIL」と書かれた目立つ大きな錠前が置かれた作業台がありました。

このスレッドは私にこう言いました。「私はスレッド 0x7954 です。私たちのボスの Python インタープリターが、add 関数を呼び出すように私に依頼しました。最初の命令を教えてください。」

私はこう言いました。「c = a + b」

「わかりません。バイトコードを教えてください。」

何が起こっているのか突然理解し、すぐにPyCodeObjectのバイトコード領域を探しました: "LOAD_FAST 0 (a)"

0x7594は、0番のセルの数字10を見つけます。これはadd関数のパラメータaの値であり、スタックに置きます。

次に、0x7594 は「次の命令」と言いました。

「LOAD_FAST 1 (b)」

したがって、数字 20 がスタックに置かれます。

次に来るのは、加算演算である BINARY_ADD です。

0x7954 は 10 と 20 の両方をすばやく取り出し、それらを加算し、結果の 30 をスタックに格納します。

最後に：STORE_FAST 2 (c)

0x7954は30を取り出し、2番のグリッドに配置します。

これを見ると、Account.class ではかつて JVM はスタックベースの仮想マシンだと言っていたのがわかりますが、どうやら Python VM も同じようです。

しかし、それらはすべて仮想マシンであるのに、なぜ 2 つの整数の加算 (BINARY_ADD) がここで非常に遅いのでしょうか?

電話の向こうの0x7954は私の考えを見透かしているようでした。「このBINARY_ADD命令が一番嫌いです。Pythonは動的型付け言語です。特定の型は実行時にわかります。たとえば、このコード

s1 = "こんにちは"

s2 = "世界"

s = s1 + s2

コンパイル後、基になる命令も BINARY_ADD なので、この命令を実行する際には型判定を行う必要があります。オペランドが整数の場合は、それらを加算します。オペランドが文字列の場合は連結します。一方が整数でもう一方が文字列の場合は、変換を行う必要があります。私にとってはなんと簡単なことなのでしょう！」

静的型付けにも利点があるようです。対応するバイトコードに直接コンパイルできます。整数の加算は iadd で、文字列の連結は他のバイトコードです。実行時にパラメータの型を判断する必要はありません。

ギル

長い間実行してきた結果、私はこれらのバイトコードに非常に慣れ、暗唱できるようになりました。この部分は本当に退屈です。

0x7954 が STORE_FAST 命令を実行した後、実際に停止しました。とても嬉しかったです。 Account.class によると、停止すると、プログラマーがデバッグする必要があることを意味します。彼らの1秒は私たちにとっては10日以上なので、長い休暇になります。

しかし、デバッグを行わずに、0x7954 はワークベンチから大きなロック GIL を取得し、CPU ワークショップを離れました。

彼は私にこう言いました。「申し訳ありませんが、Python インタープリターは、100 ティックを実行したと伝えたばかりなので、GIL ロックを放棄して、他のスレッドが CPU ワークショップを使用できるようにする必要があります。」

私は言いました。「それは正しくありません。ここには CPU コアが 4 つあります。別のコアで実行してはどうですか?」

「ダメだ、これがボスのルールだ。CPUワークショップがいくつあっても、GILロックを奪ったスレッドしか実行できない。」

「非常に多くのスレッドが GIL を待機しており、非常に多くの CPU コアが空であり、1 つのコアに問題があり、多くのコアが監視しています。何という無駄、何という無駄！」心が痛むのを免れられませんでした。

不明な時間待機した後、0x7954 は再び GIL ロックを取得し、実行のために CPU ワークショップに入りました。

バイトコード内に print 関数の呼び出しが多数あるという特徴に気付きました。

なぜプログラマーはデバッグしないのでしょうか?どうしてまだ楽しい休日が来ないのでしょうか?