[gambit-list] Question about garbage collections
Marc Feeley
feeley at iro.umontreal.ca
Fri Feb 6 14:04:47 EST 2009
On 6-Feb-09, at 11:56 AM, Bradley Lucier wrote:
> Marc:
>
> When I do the following:
>
>> (##gc-report-set! #t)
>> (define a (time (random-f64vector 10000000)))(define a (time
>> (random-f64vector 10000000)))(define a (time (random-f64vector
>> 10000000)))(define a (time (random-f64vector 10000000)))(define a
>> (time (random-f64vector 10000000)))(define a (time (random-
>> f64vector 10000000)))(define a (time (random-f64vector 10000000)))
>> (define a (time (random-f64vector 10000000)))(define a (time
>> (random-f64vector 10000000)))(define a (time (random-f64vector
>> 10000000)))(define a (time (random-f64vector 10000000)))(define a
>> (time (random-f64vector 10000000)))(define a (time (random-
>> f64vector 10000000)))(define a (time (random-f64vector 10000000)))
>> (define a (time (random-f64vector 10000000)))(define a (time
>> (random-f64vector 10000000)))(define a (time (random-f64vector
>> 10000000)))(define a (time (random-f64vector 10000000)))(define a
>> (time (random-f64vector 10000000)))(define a (time (random-
>> f64vector 10000000)))
>
> then the gc reports are
>
>> *** GC: 75 ms, 1.71G alloc, 382M heap, 76.4M live (20%
>> 55696+80018000)
>> *** GC: 64 ms, 2.01G alloc, 382M heap, 76.4M live (20%
>> 55696+80018000)
>> *** GC: 64 ms, 2.31G alloc, 382M heap, 76.4M live (20%
>> 55696+80018000)
>> *** GC: 64 ms, 2.61G alloc, 382M heap, 76.4M live (20%
>> 55696+80018000)
>> *** GC: 64 ms, 2.91G alloc, 382M heap, 76.4M live (20%
>> 55696+80018000)
>
> but after the computations are over I get
>
>> (##gc)
> *** GC: 28 ms, 2.98G alloc, 153M heap, 76.4M live (50% 54064+80018000)
>>
>
> So during the computation the heap size is set to five times the live
> size, which I did not expect, and after the computation the heap
> size is
> set to only twice the live size, which I did expect.
>
> What behavior should I expect from the gc? Setting the heap to five
> times the live size seems pretty extreme.
This looks strange for 2 reasons... a bug in mem.c and a misconception
on what the GC report means.
1) Bug: The garbage collection function receives as a parameter the
size (call it N) of the nonmovable object whose allocation could not
be satisfied and which caused the GC to be invoked. The calculation
of the target size of the new heap was incorrect, it accounted for N
twice so that the heap grew more than needed to keep the target live
percentage (i.e. 50%).
2) Misconception: The report indicates the state of the heap at the
end of the GC which is ***before*** the allocation of the nonmovable
object is attempted again (i.e. before the object of size N is
allocated by the main program). So while the heap has grown to
account for this allocation, the allocation hasn't really occurred
when the statistics in the report are generated.
Since your program is allocating really big vectors (which will be
nonmovable) the effect of these problems is most acute.
The bug has been fixed a few moments ago... please "make update".
Marc
More information about the Gambit-list
mailing list