This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Dramatic speed drop-off bug, part 2


> > ((gc-time-taken . 45) (cells-allocated . 41282)
> >  (cell-heap-size . 98304) (bytes-malloced . 4294925671) ***** Yikes!
> >  (gc-malloc-threshold . 2147421210)                     ***** Double Yikes!
> >  (cell-heap-segments (1077948424 . 1077686280) (1078485000 . 1077960712)))
> 
> Ick. It looks like scm_mallocated is being underflowed. It could be
> the simple case that scm_done_malloc is being called with too large a
> size, or that an smob free function isn't returning an accurate value,
> so you might want to make sure that you're returning the correct
> values from your smob free functions (this should be the amount of
> malloc storage freed).

When I have a routine for deleting an old SMOB, I always return zero
to the garbage collector.

static scm_sizet my_smob_cleanup( SCM x )
{
	/* free smob space */
	return( 0 );
}

My reasoning for this is that when SMOBs are doing things like database
B-trees or sparse matricies, trying to stick to a purely ``functional''
paradigm is beyond a joke. Thus, SMOBs will be modified and may change
size as they need to get more (or less) memory. If you use scm_must_malloc()
to get the extra memory then the internal variable ``scm_mallocated''
is increased to represent the internal memory. If you then call
scm_must_free(), the internal variable scm_mallocated() is NOT updated.

Thus, scm_must_malloc() and scm_must_free() do NOT form a safe bracketing
pair which can be used when SMOB code wants to play with memory.

What I use is my own malloc and free equivalents where the malloc
is just scm_must_malloc() and the free is both scm_must_free() and
an adjustment of scm_mallocated. Since I am bashing scm_mallocated
directly anyhow, I don't confuse myself by returning anything extra
from the cleanup code.


What is a pity is that scm_must_realloc() does not work as a free
when you try to realloc something down to zero size (at least I can't
get it to). The standard realloc() can be used as both malloc() and free()
when called with suitable parameters. What I would LIKE to see is a
gh_realloc() which DID work like the library realloc() so that it would
be equivalent to malloc(), realloc() and free() all in one package
AND it could update scm_mallocated in a sensible manner too.

	- Tel