substantial performance loss when running long-lived or computationally intensive programs

[Han-Wen Nienhuys]

address@hidden writes:
> The Guile interpreter comes to a near halt after making a sufficiently
> large number of calls to guile built-ins which do not appropriately
> maintain the 'scm_mallocated' variable (declared in "libguile/gc.c").

> There appears to be a widespread misunderstanding as to how
> 'scm_mallocated' should be maintained.
> 
> There is no comment in "libguile/gc.c" which describes what
> 'scm_mallocated' should contain, but by looking through the code, it
> appears that 'scm_mallocated' should correspond to the total number of
> bytes obtained through malloc currently held by the interpreter. 

Your analysis is probably correct (I didn't check in detail), but I'm
not sure if it would be a good idea to fix all of the instances. It
would touch a lot of code for a stable release. The things you found
are fixed in 1.7.

> As 'scm_mallocated' approaches 2^32, the value of 'scm_mtrigger' may be
> set to a value _intended_ to be higher than 'scm_mallocated', but ends
> up wrapping around to a value lower than 'scm_mallocated'.
> It is also possible that 'scm_mallocated' will wrap around as well.

I've added checks in scm_gc_register_collectable_memory() in HEAD to
catch these corner-case mistakes.  (This fix might be eligible for
backporting to 1.6, although they are probably moot when the other
problems you indicated aren't fixed).

One thing that does nag me, is code in srcprop.c that manipulates
scm_mallocated directly and doesn't call
scm_gc_register_collectable_memory(). Is there a good reason for this?


-- 

Han-Wen Nienhuys   |   address@hidden   |   http://www.cs.uu.nl/~hanwen