[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