海野秀之（うんのひでゆき）の外部記憶
Twitter (twilog) / RSS / アンテナ / ぶくま
たまたま辿りついた Gauche のへや at Lingr の書庫より。
濃ゆ！
GC に特化した命令を追加する機会があったとして、それって、どんなのが嬉しいのかなぁ。 ほとんどが memory operation のコストのような気がするので、 専用命令で儲かるシナリオが想像できない（←想像力がないだけ）んですけど。
自分で GC を書いてみないと、わかりっこないのかも。
ほとんどが memory operation のコストのような気がする
これは、きっと外してますね。
GC と「それ以外」の計算プロセス(SICP 用語(笑))は並列プロセスなので、両者の同期というか排他処理というかがネック。
その重たい排他処理をなんとかできまへんか、という線ならいろいろ考えられそうだ。
ソフト的に排他処理しちゃうと、コストのほとんどが memory operation のそれになるので、現状認識として間違っているわけではありませんが。
仮想メモリはあれほど手厚くハードアシストしているのに、GC はまったくソフトまかせじゃん…って、だれかそのまんまのこと言ってたな。
「命令」ではなく「仕掛け」があるといいという話し（はなしし）では。ページテーブルのHardware探索みたいなのの GC 版。<br>mark&sweep (でなくてもいいけど) が裏で動けばそりゃうれしい気はするよー。ただ user mode で kick できる仕掛けにする必要があるからねー。<br><br>って、昔(30年くらい前？)の LISP マシンが売れなかったという遺恨を持つハードベンダーがそうやすやすとやることはないと思うけどね。SPECcpu ベンチ性能が上がるわけじゃないから。<br><br>作ったら買うってんなら考えちゃる！(豪気
そう、mark & sweep なり、reference counter のメンテなりを裏ハードスレッドで、表のスレッドにオーバーヘッドを全く感じさせずにやってくれたらいいな、とは思いますね。<br>ポインタ型レジスタを更新するとパラレルにトラップするとか……<br>妄想。。。<br><br>こんな風に GC に特化して考えるんじゃなくて、もうちと汎用的なハードウエアマルチスレッドを<br>考えた方が夢がひろがりそう。<br><br>ハードウエア的スレッドプールをつくっておいて、ハードウエアトラップと同等程度のコストで<br>（理想的には表スレッドからみたらノー・コスト）プールにいるひとを起こす、とか。<br><br>> 作ったら買うってんなら考えちゃる！(豪気 <br><br>おおっ<br><br>１０万円くらいで買えるんだったら欲しい。（←ボケてるような、本気のような
いわずもがなですが、というわけで、うかいさんには言うまでもないんですが、<br><br>> ページテーブルのHardware探索みたいなのの GC 版<br><br>GC 戦略の最適化は、まだまだ、時代とともに移り変わっていきそうなので、ハードウエアアシスト機能も、硬直したものではダメですね。
だらだらと書く。<br><br>> ポインタ型レジスタを更新するとパラレルにトラップするとか……<br><br>もちろん、「ポインタ型」ってなんやねんって/はなし+/なんですが、<br>ISA が C から脱皮するってんなら、参照型と整数が区別されないってのはなさそうですよね。 <br><br>あと、現アーキのトラップって、いかにも UP (uni processor) くさい。
もっとだらだら書く。<br><br>ページ管理からの類推で、GC さんの分割統治をアシストできたらいいかも知れない。<br><br>GC さんがページに対して「このページお掃除ちゅうです」という看板をたてておいて、そこ触ったひとはページフォルトの亜種を起こしてトラップ。<br><br>この線でソフト的排他をなくせないかな。<br><br>ともかく、既存のプログラムにちょっとの改良で激はや!という路線を目指すことが肝要っすよね。<br><br>…ぜんぜん考えずに書いてるから、あとで恥ずかしくなること請け合い。(←役に立たない防護線
おおはずししてるか、そうでなければ、だれかがすでにかんがえてるか、だな。<br>#そんくらいで、くじけんな＞おれ
＞昔(30年くらい前？)の LISP マシンが売れなかったという遺恨を持つハードベンダー<br><br>(頭のとんがった?)上司には、Java が速くなりますと言っとけばいいのです。