Re: cell heap usage in 1.8 vs 1.6

[Ludovic Courtès]

Hi Kevin,

Kevin Ryde <address@hidden> writes:

> 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.

Did you try running it with HEAD?  There were small GC-stats "cleanups"
committed there that are not in 1.8, so it may be worth trying.

Besides, is your Guile compiled with `-O2'?  If not, it could be the
case that large amounts of stack space are used, but not always
overwritten, which erroneously leaves references to otherwise
unreferenced objects on the stack.  (That is unlikely to explain the
whole phenomenon, though.)

> Should the collected counts end up basically as "heapsize - liveobjects"
> every time?

I think so.

> 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?

Sorry, I don't understand what you mean here.

> 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).

I dunno.  At any rate, `(gc)' calls `scm_i_sweep all_segments ()', so
this should allow you to test this hypothesis.

Also, did you try fiddling with the `GUILE_MIN_YIELD_{1,2}' variables?

Thanks,
Ludovic.