I'm having trouble in my charting program with the amount of heap space
allocated for cells in 1.8. It ends up allocating more and more heap
(as reported by gc-stats 'cell-heap-segments and confirmed by
mallinfo()), apparently without bound. I've got between 150k and 200k
objects according to gc-live-object-stats, which should be about 5Mb of
cells, but the heap keeps growing to as much as 60Mb.
The same code seems ok in 1.6, it lives happily in about 5Mb of heap,
though it does seem to do a few more gc's than 1.8. A backport of
gc-live-object-stats to 1.6 says the objects in use are about the same
there.
I stuck in lots of printfs, which haven't told me much so far, except
that the "collected" counts seem to be lower than I'd expect, and cause
min_yield to be increased, and the heap then added to (every few gc's).
Should the collected counts end up basically as "heapsize - liveobjects"
every time? They seem to be smaller than that, but I don't know where
to look for how or why. scm_i_sweep_segment() looks slightly doubtful.
Does it deliberately not count the balance of a lazy sweep towards the
collected counts? I wondered if a gc is provoked by the double cells
being exhausted but only a little of the single cells having been
collected, leaving a small collected count in the latter (or vice
versa).
Alas I don't have a simple program to provoke the problem. Perhaps some
other big or long run program users could look at their heap consumption
vs live objects, to see if it's just me.
(define (total-heap)
(apply + (map (lambda (elem)
(abs (- (cdr elem) (car elem))))
(assoc-ref (gc-stats) 'cell-heap-segments))))
(define (count-alive)
(apply + (map cdr (gc-live-object-stats))))
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
