Thoughts on GCs

数日Twitterで散発的に呟いていたことをまとめる。

きっかけはkazuhoさんのツイート。

世代別GCの件は誤りで、コンパクションをするGCのことかな?

この「大きなブロックを確保して、先頭から順次使っていく」、まったくもって正しいんだけど話を単純化しすぎてて、実用上はいくつか問題が発生する。いつブロックを確保していつ解放するのだとか。 「サーバ等」ではリクエストを受け付けてからメモリを確保してレスポンスを返したら解放すればだいたい上手くいく。しかしそれでもリクエストローカルではないデータもあるしこういうカスタムなメモリアロケーションはCじゃないとできない。

GHCにリージョンとかの名前で入ってた気がしたけど探しても見つからず。GHCのメモリにはみんな困ってるらしく、検索ノイズが大きかった。

下記の世代別GCはこれで合ってる。

因みにH2Oはアロケーションを使い分けてるらしい。

CならH2Oのように適材適所のアロケーション戦略がとれるがやっぱり手動メモリ管理を放棄したGC付き言語だと厳しい。

また、今回の自分の話はサーバとかを念頭に置いていて、常にこれが最適とは限らない。

ところでlldはメモリを開放しないというのをruiさんが度々アピールしているけどそれはGCのある言語でもできる。

本当にGCはない方がいい。

で、やっぱりGCのある言語でもH2Oのようにリクエスト毎にリージョンを作って破棄したい。色々考えるに、このリージョンは丁度fiberとかと寿命が一致するのではと思いつく。

階層化したのはfiberに親子関係があるからと、長寿オブジェクトも親のリージョンに置いとけば寿命長く出来るだろみたいなノリ。もちろんfiberのリージョンの上にはスレッドのリージョンがあるしグローバルなリージョンもある。

しかしやはりAPIの問題がある。ところでここまででてきたリージョンは「一時的に用意されたメモリのカタマリ」くらいのゆるふわな用語だけど下記のregionはちゃんとした方のリージョン。(CF リージョンについて)

これは似たようなものがあったはず。

今調べたらこれだった。 Hierarchical memory management for parallel programs まだ読んでないので自分の考えと近いかは分からない。

で、自分の考えが合理的か考えてみた。

これは少し間違ってて、自分は親のメモリにもアクセスしようとしてるからスタック変数よりは柔軟になる。しかしやっぱりそれをやろうとするとリージョンになる。 つまりリージョンを前提にした言語設計になる。

結局、既存の言語に簡単には入らなそう。世知辛い。

余談

Written by κeen