JavaVMの実装
classfile上では、ひとつのmethodにつき、
が別扱いになってるけど、一つのスタックフレーム上に持っちゃいけない理由はないんだよな。それどころか、コンテキストごとにスタックフレームを持つ理由すらないというか。C言語の局所変数や戻り値はスタックフレームのlinkとunlinkでやってるわけだし(気の利いたコンパイラだと、ファイルスコープの関数はレジスタ経由になるのかな。でもレジスタってポインタ持てないしなー。仮引数やlocal変数に対して&を使わないのならレジスタに展開されるかも。戻り値は・・ファイルスコープでもスタック経由かなー)。
あ、いや、もちろん、スタックフレームを一つのスタック上に持つとバッファーオーバーランとかの温床になるのでできればthiscontextはinvokeごとに持つべきだとは思うんだけど、invokeに対するコストを最小化するのであればスタックでも別にいいんだよなー。Jazzileはinvokeのたびにmallocしているとは思えないので、スタックポインタは１スレッドにつき１つという作りなんだろうな。
invokeごとにスレッドを一つ生成し、戻り値はfutureオブジェクトで返すという極端なJavaVMがあってもいいのかな？ 全Java値(byte〜long+リファレンス+配列)に1ビット追加してFutureオブジェクト(Future基本型？)が実際に戻り値が返ってくるまではスレッド自体が待つの。何も考えずにプログラムを組んでもマルチコア＋グリッドに最適化。ほんと？ コンテキストスイッチのコストの方が大きくない？
今度作ってみましょう。
この間作ったJavaVMはJavaのくせになぜかプロトタイプ型のVMになってて(newInstanceがクラスオブジェクトの限定的clone。クラスオブジェクトでもインスタンスフィールドをダミーで持ってる)、thiscontextがしっかりbytecodeEngineから参照できました。いや、thiscontextを参照するbytecodeないけど。クラスオブジェクトがinvokevirtualで参照するべきバイトコードをinvokeのたびにさかのぼらなくてもいいようにプロトタイプを作った時点で全部展開してキャッシュしてました。
あと、実行中にも特定インスタンスのmethodのbytecodeを変更できるという動的言語チックな作りでしたけど(バイトコードcheckcastとinstanceofのためだけにクラス継承を持ってた。ほかでは使ってない。この2つのbytecodeがなかったらクラスへの参照すらも持たなかったかも。クラスオブジェクトへの参照はsuperのために必要だけど)、これ、速度のためにこうしてたんだよなー。プロトタイプ型の言語が遅いなんていったのはどこのどいつだ。
はい、昔の私です。やっぱ、やってみると見えるものがあるなぁ。
