はじめに

mrubyのJITなるものを作っています。これは、mrubyにJITコンパイラを加えたものです。一定の成果 は得られたのですが、色々問題も発生してきました。もともと、動くことが第1目標で出来る限り無難な実装を選択したため、これ以上の拡張は厳しい気もします。

こんな問題があります。このような問題に対して解決するような新たなバージョンを検討します。

　マルチスレッド

　当然ながらマルチスレッド化は全く考えていません。さすがにmrubyの設計思想に反して大域変数を使うようなことはしていませんが、生成されたコード領域はグローバルで排他制御していませんのでマルチスレッドには対応していません。そのため、H2Oでの使用は事実上不可能です。

メモリ効率

　コンパイル時の型情報やVMに戻る際のレジスタ情報などmrubyのJITで必要なデータを保持するためにメモリを使うのですが、これが何も考えずにad-hocに設計したため非常に無駄の多いものになっています。luajitのコードを読み、もっと効率の良いデータ構造が設計出来ることに気づきました。

移植性

もともと、mrubyのJITはx86　32bitのみで動くように開発しました。その後、x64でも動く様変更しましたが、armでの動作などは全く考えていません。

コード領域の無駄遣い

　mrubyのJITはメソッドの再定義など動的な性質に対して、コードの自己書き換えで対応している場合があります。ところが自己書き換えで無効になったコード領域はそのまま何も使われずそのままになります。コード領域に対するGCが望まれますが、現状の構造ではそれは不可能です。

マルチスレッド

　ここでいうマルチスレッドとは3つの意味があります。１つはmrubyのインスタンスがmrbを複数用意することで複数存在しそれぞれがマルチスレッド動く場合。H2Oはこの状態で動いているためH2Oに対応するためにはこの形での実行が出来ることが必要になります。2つめは、コンパイラ中で並列で動くこと。例えばコンパイルをバッググラウンドで行うとかはこれにあたります。3つめは、コンパイルされたコードがマルチスレッドまたは並列で動くこと。mrubyは標準ではマルチスレッドはサポートしていませんが、マルチスレッドまたは並列に実行するようコンパイルすることは可能であるような表記は存在します。