確かにこういうケースを考えるとシンボルとキーワードはGCされた方がありがたいな。実際シンボルを作っては捨てるみたいなのを書いたらメモリーが大変なことになったし。
https://t.co/Ft64oBlIDb
— Kei (@tk_riple) October 17, 2014
こういったいきさつがあって、シンボル(とその他2つ)をGC対象にしたのだが、どうもweak hashtableの実装がまずいらしく、多少改善された程度のメモリー消費量にしかなっていない。とりあえず実装を見直してみると、weah hashtableとhashtableの実装上にweak boxを載せてそれっぽく見せているのだが、どうもこのweak boxが消えないのでエントリー数が増え続けるという感じみたいである。一応キーが回収された際にエントリーを消すような小細工がされてはいるのだが、なぜか上手く動いていない感じである。
どうするか？というのがあるのだが、解決方法は2つくらい案があって、
- Weak hashtableを別実装にしてしまう。
hashtable-ref等の手続きを共有して使えないのだからコードを共有する必要があまりなくね？という発想。 - Hashtable側のAPIをリッチにする
バケツの割り当て等を外部から操作できるようにしてしまえば何とかなりそうじゃね？という発想。
どちらの道をとったとしても、weak boxの扱いをどうするかという問題は残るのでこれはちと考える必要がある。
追記(2014年10月18日)
よく考えてみればエントリー数が減らないのはweak hashtableの値がGCされた際に対象のエントリーを削除しないのが問題なので、値がGCされた際に対象のエントリーを削除するように変更した(後方互換を保つためにフラグを一個追加した)。なんとなく、動いているっぽいので当面はこれでよしとしよう。
2 comments:
Key-weakなhashtableは面倒ですよね。finalizerでGCされたエントリ削除してますか? Gaucheだとどのスレッドでfinalizerが呼ばれるかが不定なので安全にハッシュテーブルにアクセスすることができず、どうしようか迷ってて止まってます。(多分、通常のアクセスのタイミングで空のweak boxを見つけたら随時回収してゆく、あたりが落としどころかなとは思いますが、refするだけで構造を変更するのもちと気持ち悪い)
finalizerでエントリ削除かつ明示的なdeleteでfinalizerの削除してます。なので多少パフォーマンスが悪いのが辛いところですね。今回の変更でvalue-weakかつエントリ削除が入ったのでさらにパフォーマンスが・・・
スレッドはそういえば頭からすっぽり抜けてました。う～ん、問題になるかなぁ。
Post a Comment