#GaucheでBoehm GCにした理由のひとつに、Cレベルでこの手のGC protectをいちいち手で挿入するのを避けたかったってのがあるなあ > http://www.kt.rim.or.jp/~kbk/zakkicho/11/zakkicho1107a.html#D20110708-2 #「自前GCが認識するオブジェクト」が「自前GCが認識しないオブジェクト」を指すポインタを持ってて、後者だけを他の関数に渡すところでは必ず、関数呼び出しが帰ってくるまで前者への参照を保護しておく必要がある。
#でもlongjmpなどで例外処理を実装してると確実に保護を取り除くのが厄介だったりする。結局JNIみたいにCの世界へオブジェクトを渡すところでがっちり管理するか、それが嫌ならメモリは全部GCで管理するか、ってとこになる。
#上で紹介されてる記事は%raxがcaller savedだから云々とあるけど実はそれは関係無いよなあ。str自体がRSTRING_PTRとRSTRING_LENを取った後は使われないんだから、コンパイラは例えばRSTRING_PTRの値で元のstrのレジスタを上書きすることだって許される。
#Google+ってGoogleアカウントに紐つけられちゃうのかぁ。ちょいと気味が悪いのう。別アカウント作って試そうかなあ。
#というかRubyくらい歴史があってユーザがいるような処理系でもこの手の問題が出るのか。。
#そう、だからなおのこと、自分がこういうケースを漏らさずに対応できる自信がない。
#はい.この手の問題が残っています.というか,昔から問題になっていました.GC の問題なので,なかなか発見されない,という.
#あと,tail call optimization が gcc 4 のあるバージョンから aggressive に入ったおかげで
#(4.2 だったかな?)
#この手の話が顕在化しやすくなったということもあります.
#一つの関数内で新たに一時オブジェクトを作って、その部品を他の関数に渡す時に一時オブジェクトへの参照を失ってないか、ってパターンについては自動的にスキャンできそうな気もするな (false positiveはあり得るだろうけど、ヒットしたところを人間が改めて検査すればいい)。