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.
Brad
Afficher les réponses par date
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
-
Bradley Lucier -
Marc Feeley