GGCは相変わらずややこしい

ILog

んんん。GGCはスタック上のオブジェクトをマークできないという問題が今頃露呈。上のプログラムで、ループ回数が22になってるのは、GC動く/動かないの境界がそこらへんだったから、とか。
GCのあたりは問題が出たら困るのでなるべく危なそうなテストは避けるようにしてきたんだけど、ついに発見してしまう。いや、うん、どうしようか。
GCのプロテクト用オブジェクトをいちいちヒープから拾ってきてたら勿体無くてしかたがないのでスタックにのせてたんだけど。
仕方ないので、専用のアロケータ書くか…



あああーあ。色々。色々。もう普通に保守GC使ってくれりゃいいのになぁ…でも、多分、ここは僕の使い方のほうが間違ってんだけど。
いや、嘘だ。嘘。このぐらいいくらでも対応できる。この程度の逆境に負けててはいけない…って、もう何言ってんだかわかんないな。


ここから下は本当にメモ。
上のフィボナッチ数でSpiderMonkey、Ruby、Pythonは0.1秒かからずに終わってるので、どこらへんが違うか見てたら、多分、整数の扱いが違うとかのような気がして、整数値はオブジェクトじゃなくて、生でそのままレジスタに乗っかる値になってて、でも、GGCはそこらへん無茶できないような気がして、どうしようかと思ったんだけど、

struct ilog_slot GTY(())
{
  struct tree_common common;

  tree key;
  union slot_value {
    long GTY((tag ("1"))) fixlong_value;
    tree GTY((tag ("0"))) tree_value;
  } GTY((desc ("((long)&%1) & 1"))) value;


  location_t *last_define;
};

こんな感じにすればいい、と、いうのがわかって、それもまた別にいいんだけど、さすがに、いちいちこれを全部に埋めるのは辛いのと、あと、これやると、整数と、GCC内の整数が違うので

build(PLUS_EXPR,int,3,4)

これができなくなって、どうしようか、と考えるも、別に整数演算なんかそんなに出てくるわけでもないだろうし、もう今のままでいいと思った。
要するに面倒だから今のままにしとく、という結論。整数がボトルネックになるようだったら考えなおそう。


まあいいか。Rubyは整数も本物のオブジェクトにしてると思ってたんだけど、そこらへん適当にごまかしてたんだなぁ…と、いうのがわかったので、収穫ゼロってこともないだろう。そんなの知ってて何の役に立つかは知らんが。