私が書いているものは型推論器ではなくなんなのか

Miura Hideki — Sun, 03 Jun 2018 06:20:54 +0000

はじめに

現在、mruby用のコンパイラを書こうとしていてその一環として、こんなものを作っています。永らく型推論器だと思っていたのですが、どうも型推論器には当たらないことが分かってきました。そこでここでは今作っているプログラムについて説明します。
基本的にやっていることはプログラム全体を走査して型情報を集めて表示する(またはそれを使ってコンパイルする)ということです。一言で行ってしまうと簡単ですが実際に実装しようとするとなかなか大変です。

まず型情報を集めると言ってもどこから元を集めればいいのでしょうか？命令列は簡単に得られますが、そのオペランドになっているレジスタに何が入っているかは自明ではありません。明らかにレジスタの内容が分かる定数のレジスタを元にレジスタの参照関係が扱いやすく整理されている必要があります。さらに、mrubyのVMではデータはレジスタにだけあるのではありません。インスタンス変数、グローバル変数、定数などもあります。こういったものの型も集めなければ全体の型情報は得られません。そのため、型情報を集めるための中間コードの設計がとても大事になります。この辺の話は中間コードの章で説明します。

集める型をどのような構造に入れるかも自明ではありません。たとえばRubyのカオスな型システムだとある時点でFixnumだと思ってたものが別の所だとStringだったとしても不思議ではありません。いろんな変な状況が現れても大丈夫な構造を用意する必要があります。
また、Rubyではメソッドの引数についてオーバーロードをゆるすというよりオーバーロードと言う言葉すら無意味なほど ~~ガバガバ~~ 自由度の高い言語なのでそのあたりを何とかする必要があります。このプログラムではTUP(Tuppleから)という概念を使ってそれを実現しています。これも重要な概念でしょう。

ここまで説明すると枠組みが出来上がりますので、ここの命令毎にルールを説明します。命令によっては色々ヒューリスティクなことをしているのでまあ説明する必要があるでしょう。

VMの命令のルールを説明して終わりなわけがありません。mrubyにはC(死んだはずなんだけどね)で書かれたメソッドがありこれら毎に型のルールを指定しないといけません。多くは自明なものですが中には複雑なルールもあります。

次に条件分岐の扱いです。普通は条件分岐は辿れるとこ全部を辿らればいいのですが、例えば、

  if !block.nil? then
     block.call(n)
  end

みたいなコードでblockがnilではcallは呼べないよ　というエラーは誰もが受け取りたくないでしょう。そういうわけである程度条件分岐の条件を見て適切な制御をしています。その説明も章を設けて行います。

とりあえずこんな感じの文章が出来るはずです。

中間コード

このプログラムではmrubyのバイトコード命令毎に入力から出力に型を伝搬していくのが主な動作になります。この時、入力と出力というのは自明ではありません。そういうとレジスタには番号が付いているから簡単では？と思われるかもしれませんが、同じレジスタの番号でも上書きされていれば別のレジスタとして扱わなければなりません。
昔作ったコンパイラの経験から条件分岐の処理は特に面倒になるため基本ブロックにきっちり分けて管理する必要性を感じました。
また、mrubyのJITの経験からレジスタ割り当てをおこなう場合はレジスタの生存期間が簡単にわかるようになっている必要があるという知見を得ました。

以上のことから中間コードはSSAベースが最適と言う結論になりました。ところが、mrubyのVMのバイトコードをSSAに変換すると言うのはなかなか煩雑なものです。考えた末、SSAと同等のコードが得られる方法を思いついたのでそれを実装しています。この方法ではコードはグラフになるためテキストにエンコードするのが煩雑になるという欠点があります。

mrubyのバイトコードをSSAに変換するには次のような手順で行います、
　　* バイトコードを分岐を含まない基本ブロックごとに分ける
　　* 同じ名前のレジスタでも代入ごとに別の名前を付けて区別できるようにする(単一代入化)
　　* 基本ブロック間でのレジスタのやり取りはどこのブロックからやってくるのか明示する(phi命令)

基本ブロックに分ける

バイトコードを分岐を含まない基本ブロックで分けるためには命令列(irep->iseq)について切れ目の位置を記録しておいて、その切れ目の位置で分ければよいわけです。切れ目の位置は次のようなところです。
　　* JMP/JMPIF/JMPNOT/RETURN/RESCUE などのpcが単純なインクリメントではない命令
　　* 上記命令の飛び先
　　* 命令列の終わり(最後は必ずRETURNで終わるので実質必要ない)

命令列を分けた後、命令の実行関係で基本ブロックごとにリンクを貼ります。RETURN/JMPなどは1本ですが、JMPIF/JMPNOTは2本(条件が真偽それぞれの飛び先)あります。

単一代入化

おそらく一番めんどくさい話。同じ名前のレジスタであっても途中で代入すると別の名前のレジスタとして扱わないといけないと言う話。SSAを知っている人以外は意味不明だと思うので、SSAの別の資料を見てください。学術的にはレジスタのリネームとか色々やりようがあるだろうけど、ここでは簡単で泥臭い方法を用いてます。

その方法とはレジスタをオブジェクトとして実体を用意してレジスタの代入のたびに新しいレジスタをアロケートするというものです。つまり、SSAで面倒くさいレジスタの名前付けがオブジェクトのアドレスで勝手にできてしまうわけです。しかも、型推論にはレジスタにいろいろな付加情報を加える必要がある(例えば型)のでレジスタをオブジェクトにするのはとても都合の良いことです。

中間コードを図にするとこんな感じになります。

命令オブジェクトは@OPに命令のオペコードがシンボルで入り、@inregが入力レジスタの配列、@outregが出力レジスターの配列です。ADD R2, 1, :+みたいな命令ではR2は入力レジスタであり、出力レジスタになるわけですが、別のレジスタとして取り扱います。出力レジスタは必ずその場でアロケートした(または、インスタンス変数みたいに別の場所に格納してある)レジスタになります。入力レジスタと出力レジスタは必ず分離することが大切です。前回のytljitでは入力レジスタと出力レジスタを区別しなかったばっかりにうまくいかなかった知見があります。

型表現

前章で説明した中間コードを辿って言ってレジスタオブジェクトの型を決めていきます。レジスタは2つのレベルで型の情報を持ちます。それぞれ@same, @typeというインスタンス変数に保持します。
@sameは自分(レジスタ)と同じ型を持つレジスタの集合を表します。@typeは実際に自分の型を保持します。

なぜ、@sameが必要でしょうか？確かに、後から説明するようにレジスタがもつ型情報を別のレジスタに拡散していく形で型の推定をおこなうわけですが、@sameを使わずに@typeに直接入れてもよさそうなのにって思われるかもしれません。しかし、それではうまくいかない場合があります。元になるレジスタも実は型が確定していなくて後から確定する場合もあるからです。そういう場合には、@sameに同じ型のレジスタだよって情報だけ覚えておいて、あとから@typeを更新します。

また、@sameは複数のレジスタを入れることが出来るので、必ずしも@sameに入っているレジスタと同じ型になるとは限りません。例えばif文でthen節とelse節が別の型を返した場合、ifの型はthen節とelse節と違うそれらのユニオンになります。

型オブジェクト

　型そのものは型オブジェクトという型を表現するオブジェクトを用意します。型オブジェクトが満たすべき条件は、同じ型は同じに違う型は違うと区別できることです。簡単そうですが、非常に難しくおそらく最後まで細かい条件づけの調整が続くと思われます。型オブジェクトは型を表現したものですが、さらに分類できそれぞれサブクラスになっています。

BasicType

PrimitiveType

LiteralType

ContainerType

ProcType

tup

Rubyは引数に型の制約を付けるという発想が無いため、メソッドの引数は必ず多相性を持ちます。同じメソッドでも別の型のオブジェクトを引数で渡すと全く別の動作をする可能性があります。つまり、違う引数の型で呼び出す場合は同じメソッドであっても違うメソッドとして取り扱うべきです。しかし、メソッドが同じか違うのかを区別する方法が必要になります。ナイーブな方法としてレジスタの型情報を引数の型の組と型のテーブルにするという方法が考えられます。これは、ytljitで使用したのですが、非常に効率が悪いです。そこで、引数の型の組にユニークな整数を割り当てそれをキーにするという方法を採用しました。この整数をTUP (Tupleより)とこのプログラムでは呼んでいます。

Array

Proc

Procはメソッドやブロックのオブジェクトです。irepと環境(mrubyのEnvオブジェクト)をwrapしています。Procオブジェクトで難しいのは2つのProcオブジェクトがあった場合の同一性です。一見、irepだけ見ればよさそうですが、それではうまくいかない場合があります。
例えば、

  def foo(&block)
    self.collect {|x| block.call(x)}
  end

のようなプログラムは {|x| block.call(x)} の部分のProcオブジェクトはirep(プログラムコード)だけだと常に同じになってしまいます。ここで、blockに例えばFixnumを返すProcオブジェクトとFloatを返すProcオブジェクトを渡しても同じ型になってしまうので、たとえばFixnum|Floatという型になってしまいます。

そこで、Procオブジェクトは持っている環境に閉じ込められている変数の型も同一性を判定するのに用いるようにしています。こうすると、blockは{|x| block.call(x)}の環境に閉じ込められている変数ですので、blockの型によって別々のProcオブジェクトとして扱うことが出来ます。

インストラクションのルール例

LOADNIL

MOVE

SEND

組み込みメソッドのルール例

Array#[]

条件分岐の扱い

mrubyのJIT ver2　の構想

Miura Hideki — Wed, 06 Dec 2017 10:13:06 +0000

はじめに

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は標準ではマルチスレッドはサポートしていませんが、マルチスレッドまたは並列に実行するようコンパイルすることは可能であるような表記は存在します。

DEV Community: Miura Hideki

私が書いているものは型推論器ではなくなんなのか

はじめに

中間コード

基本ブロックに分ける

単一代入化

型表現

型オブジェクト

BasicType

PrimitiveType

LiteralType

ContainerType

ProcType

tup

Array

Proc

インストラクションのルール例

LOADNIL

MOVE

SEND

組み込みメソッドのルール例

Array#[]

条件分岐の扱い

mrubyのJIT ver2 の構想

はじめに

マルチスレッド

メモリ効率

移植性

コード領域の無駄遣い

マルチスレッド

mrubyのJIT ver2　の構想

　マルチスレッド