Re: Guile 1.8 GC issues

[Han-Wen Nienhuys]

2007/10/25, Ludovic Courtès <address@hidden>:
>   * The "minyield" grows too fast.  This is a consequence of
>     `scm_iadjust_minyield ()' seeing too little collected cells.
>     Actually, the "big" increase of "minyield" (visible on my graphs)
>     occurs when it sees zero collected cells.
>
>     Two (potential) issues: (i) the computation of "minyield" is too
>     "aggressive", and (ii) the collector incorrectly reports the number
>     of collected cells in some cases.
>
>     Having a too high "minyield" also makes `scm_i_gc_grow_heap_p ()'
>     return true in situations where it shouldn't.
>
> Since I believe you know the current GC quite well, I'd like to get your
> insight about this, when your time permits.

You have done more careful analysis than I could have done from my
chair and my memory. However, regarding the 'agressive' minyield, you
have to keep in mind that there are also cases where a program is in
construction/parse phase and allocates many long lived objects.  In a
GC during this phase, little cells will be reclaimed, and the right
solution is to let the memory grow with the live objects. In GUILE 1.4
(if memory serves me), there was a complicated scheme that tried to
cater for a case similar to yours. The result was that lilypond spent
half of its time running GC, trying and failing to reclaim long-lived
objects.

Maybe it might make sense to use a smoothed number of live objects (ie
averaging over a couple of runs), so that an ocasionally badly timed
GC does not make memory use explode.

Have you looked at Hans Boehm's GC benchmarks?  He has collected
several test cases; it is wise to run any changes through all of the
test cases, so you can make sure you don't accidentally break
performance in one case while fixing something else.

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen