日曜学校の時間、末娘をだっこして歩き回りながらレッスンを聞いていた(あんまり集中できなかった)以外はごく普通の日曜日。神権会のテーマは「ポルノグラフィー」。Matsue〜」の開所式が開かれた。TVの夕方のローカルニュースに登場したりしてしまった。なんだかおおげさなことになってしまったなあ。ニュースを見た長女には「お父さんっ、なんで一人だけジーンズなのよっ」などと怒られてしまった。いいじゃん、これが私の普通なんだからさ。先週付けで中途入社した人の歓迎会。結局テルサ(オープンソースラボのある建物)にあるレストランで。18人で、お店のビールを全部飲んでしまったらしい。Rails昨日、式典があって受賞作が発表になったそうだ。私は行けなかったのでビデオ出演。私が選んだ「小槌」は、大賞もゲットしたらしい。Japanに記事も出ていた。この設立総会は立派なものだ。福岡県知事も来たりするし。出席者も300人以上いたんじゃないかな。「Rubyの未来」と題した講演を行う。ありがたいことでもあり、はずかしいことでもあり。本物の「Rubyバブル」が来ていることを実感する。これからは中身を詰めていかねばならない。その後、懇親会ではいろいろな人と挨拶する。途中でなくなってしまった。NaClのだけでなく、楽天フェロー名刺までなくなるとは予想外だ。福岡の人は名刺交換が好きだとか。いずれにしても、次回があれば今回以上に名刺を持参しようと思う。Rubyビジネス・コモンズ設立総会を開催,麻生福岡県知事やRuby開発者まつもと氏らが登壇:ITpro二次会では胴上げされた。長いこと生きてたけど胴上げされたのは初めてだ。普段接することのない体育会的ノリに新鮮な驚き。RailsRailsが世に出てちょうど3年、という話。Railsは世界を変えてしまった。冷静に思い返してみれば、私以外の人にとっては、今の方が幸せな世界ではないかと思う。語られるというのはソフトウェア業界はじまって以来のことではないだろうか。これからも世界は変わりつづける。その中心に近いところに居られたら、と願う。実は本当にワトソンがそのように行ったと言う証拠はないそうだ。その時とは違う文脈で「5つあれば足りる」という話。これからしばらく(Webのおかげで)集中に振れそうだ、という予測なのだろう。P2Pのような技術によって分散に振れるんじゃないかなあ。こっちでまとめることにする。Twitterの発言*1はこんな感じ。利用中のオブジェクトはGCに回収されないよう保護する必要がありますが、Cのスタックはポータブルに参照できません。そこでC関数実行中に生成したオブジェクトは全部「生きている」とみなす事で保守的に保護します。08:16:45arenaの目的(2)。この保護のためにオブジェクトを記録しておく領域がarenaです。mrubyではデフォルトで100個のオブジェクトを登録できます。08:19:02save/restoreの仕事。現状arenaのサイズは固定なのでC関数実行中にあまり沢山オブジェクトを生成するとarenaが溢れます。08:27:02save/restoreの使い方。オブジェクトを生成する領域の前後をsave/restoreで囲みます。囲まれた範囲内のオブジェクトが保護されなくなりますから、どうしても必要なものはrestore後mrb_gc_protect()で改めて保護してください。08:33:61これを再度まとめてみよう。error」という「謎のエラー」に悩まされることがある。arena」という領域があふれたというエラーだ。プログラムのどこかから参照されているかどうかを判定する必要がある。これはルートと呼ばれる参照から直接・間接に参照可能かどうかで判別する。ルートには、ローカル変数・グローバル変数・定数などが含まれる。VMの中でおさまっている時にはこれは問題ない。VMの持つルートはすべてGCからアクセス可能だからだ。問題はCで記述された関数を実行中の時。C変数からしか参照されていないオブジェクトは死んでいると誤解してしまう。生きているオブジェクトを回収してしまうのは、GCとしてもっともやってはいけないバグだ。Cの変数をルートとしてチェックしている。それが整数を意味する値なのか、ポインタ値を意味する値なのか判別することはできない。この「安全側に倒す」というポリシーのことを「保守的」と呼ぶ。され、このようなCRubyの「保守的GC」にはいくつか問題がある。その最大のものは「移植性のある方法でスタック領域にアクセスする方法がない」ということだ。移植性の高さを実現しようとするmrubyのような処理系では使えないってこと。そこで、mrubyは別の方法で「保守的GC」を実現した。述べたようにCRubyは、Cスタックをスキャンしてゴミのように見えるがゴミでないものを保護している。その方法が使えないmrubyは、より保守的なポリシーを採用した。少なくともゴミでないものを回収してしまう問題は回避できるんじゃないかと。移植性が高いまま、保守的なGCを実現できることになる。CRubyで時々発生する「最適化で参照が削除されてゴミでないのにGCされた」問題とも無縁になる。C関数の実行が終わるとその間に登録されたオブジェクトはポップされる。arenaの存在は別の問題を引き起こすことがある。そのサイズはデフォルトで100とかなり小さめに設定されている。現状は100にしている。arenaがあふれることになる。その対策に用いるのが、表題のmrb_gc_arena_save()とmrb_gc_arena_restore()というふたつの関数である。idx)はarenaのスタック位置を保存された位置に戻す。arena_idx);というような使い方をする。overflowを避けるわけだ。いうものの、具体例を見ないとわからないケースもあるだろう。ここでは、Array#inspectのソースを見てみよう。それらを結合して配列全体のinspect表現を作ることにある。処理途中に生成した各要素の文字列はもはや不要になる。arenaにこれらのオブジェクトを登録しておく必要もない、ということだ。生成中の配列inspect表現文字列に結合mrb_gc_arena_restore()でインデックスを復旧という手順により、arena領域の消費を抑えている。mrb_gc_arena_save()の呼び出しよりも前に生成していることである。しないと、必要なオブジェクトがGCで回収されてしまうことになる。そのうちの一部だけを参照し続けるというケースも考えられる。obj)を呼び出して、そのオブジェクトをarenaに再登録する必要がある。いうことを、Twitterだけで説明するのは現実的じゃないよなあ。errorになることだ。戻り値を使わないmrb_funcall()のようなものを用意すればいいんだと思うんだけど。いい名前が思いつかないんだよなあ。