In article <87veqbfwbv.fsf / fsij.org>,
  Tanaka Akira <akr / fsij.org> writes:

>> まだプロファイルは取ってみていないのですが，この結果を見る限りでは，GC 
>> アルゴリズムそのものの問題というよりは，GC開始のスレッショルドや，アロ
>> ケーション方法などの問題と考えた方が妥当なのでしょうか？
>> また，このような結果になることはよく知られた事実なのでしょうか？
>
> GC をどういうタイミングで起動するか、あるいは、そもそも GC
> をするか OS にメモリを要求してヒープを広げるか、という判断が
> あまりうまくいかないことがある、というのは確かだと思います。

GC 後にどのくらい空いてればヒープを広げるか、という基準をい
じくると改善できるようですね。

4096個空いてれば、というのを、2割空いてれば、とすると、こう
でしょうか。

(現在の) GC はヒープのサイズに比例したコストがかかるので、定
数しか空かないならわりに合わないってことでしょうね。

この問題に対して、世代別 GC が正しい解かというと、さて、どう
かな。

Index: gc.c
===================================================================
RCS file: /src/ruby/gc.c,v
retrieving revision 1.241
diff -u -r1.241 gc.c
--- gc.c	29 Jun 2006 14:57:41 -0000	1.241
+++ gc.c	6 Jul 2006 14:14:55 -0000
@@ -1057,6 +1057,14 @@
     int freed = 0;
     int i;
     unsigned long live = 0;
+    unsigned long free_min = 0;
+
+    for (i = 0; i < heaps_used; i++) {
+        free_min += heaps[i].limit;
+    }
+    free_min = free_min * 0.2;
+    if (free_min < FREE_MIN)
+        free_min = FREE_MIN;
 
     mark_source_filename(ruby_sourcefile);
     if (source_filenames) {
@@ -1099,7 +1107,7 @@
 	    }
 	    p++;
 	}
-	if (n == heaps[i].limit && freed > FREE_MIN) {
+	if (n == heaps[i].limit && freed > free_min) {
 	    RVALUE *pp;
 
 	    heaps[i].limit = 0;
@@ -1117,7 +1125,7 @@
 	if (malloc_limit < GC_MALLOC_LIMIT) malloc_limit = GC_MALLOC_LIMIT;
     }
     malloc_increase = 0;
-    if (freed < FREE_MIN) {
+    if (freed < free_min) {
 	add_heap();
     }
     during_gc = 0;
-- 
[田中 哲][たなか あきら][Tanaka Akira]