#「with-input-from-portを使わないやつ」です。説明不足でした。単純に引き算をすればいいのですよね? free-bytesの量も変動するようなので、これを使って使用メモリを計算するということかなあとか思ったのですけども。
#その同じなるだろうという見込みは、つまり生成したCSVオブジェクトの総量は変わらないから同じになるだろうという考えでした。これを計算するには、free-bytesをtotal-heap-sizeから引けばいいということですか。
#PROT_NONE で mmap しなおしているところがあるので,そこを通るなら RSS は減りますね.VM space はがめたままだけど.その値は total-heap-size に反映されるみたい.
#(とりあえず、CSVの確保量を算出してみたのですが、完全に一致はしないのですね。わたしには、許容される範囲なのかどうかという判断ができないのですけれど。 https://gist.github.com/yamasushi/5718069 ) #with-input-from-portを使うだけで、少しheapに残るように見えるのですが、これはgcの動きから生まれる誤差と言う解釈でいいのでしょうか? (ken_all.csvを読むだけのスクリプトです。heapが1.7Mほど増えているように見えます。) https://gist.github.com/yamasushi/5719441 #(read-line)とするべきところを(read-line port)としておりました。こう修正すると差は1M弱です。これだけの変更で影響を受けるとは・・・・空間性能を測るのは大変なことですね。 https://gist.github.com/yamasushi/5719441 #(define (test)
(let1 x (make-vector 100000000 #\a)
#?=(gc-stat)
) )
(begin0 #t
(gc)
#?=(gc-stat)
(gc)
(test)
#?=(gc-stat) ) ; のxで確保されたメモリはどこで開放されているのでしょうか? heap-sizeからfree-byteを引いた値が減らないのですが・・・・どうもGCをよく理解できていないようです。orz
#このコードの場合、xへの参照がスタックに残っている可能性がありますね。testの後でスタックを消費する手続きを呼び出せば、スタックが上書きされるのでいずれ回収されるのではないかと。gcというのは「参照がなくなったオブジェクトは*いずれ*回収される、というものですが、それがいつ回収されるかについては幅があるので、思うようなタイミングで回収させるのはかなり難しいです。
#手続きのtrace機能って欲しいと思ったことはないんだけど、メソッドのtrace (ジェネリック関数呼び出しがどのメソッドをどういう順で呼んでるか) はあってもいいかなと思った。呼ばれるはずのメソッドが呼ばれない、でしばらく時間を無駄にしてしまったので。
#GCの件、ご教示ありがとうございます。ということは、(test)がメモリを必ず開放しているかどうかを判定するすべが無いということでしょうか?
#「確実に判定」するには、今のところC APIのScm_GCSentinelを呼ぶなどする必要があります (いくつか裏技的にfinalizerをSchemeで書く方法はありますが)。実装上なるべく確実に解放したい場合は、上のコードならxにset!して参照を上書きすることなどはあります。しかしBoehm GCの場合、false pointerがあり得るので、意図せずオブジェクトが生き残る可能性は常にあります。
#なるほど。ありがとうございます。「空間」を知るのが「時間」を知ることより困難というのは面白いですね。