Re: Dramatic speed drop-off bug, part 2

[Greg Harvey <Greg.Harvey@thezone.net>]

Telford Tendys <telford@eng.uts.edu.au> writes:

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

Actually, the whole method kind of irks me, though I don't have any
really good reason (just a nagging `I don't like that'). scm_must_free
should do the grunt work with scm_mallocated, but it's not something
thats easy to do portably (or lightly, if we have to keep track of
things ourselves). glibc's malloc has a malloc_usable_size function,
which we could use; it's not always 100% correct for the actual size
of the storage (a quick test of realloc'ing a 100 byte chunk to a 150
byte chunk gives malloc_usable_size(chunk)==156, and a 1024 byte chunk
gives 1028... not sure if this is a bug or just a result of the
allocation policy), but as long as it reports the same value each
time, it doesn't matter much. I'll do a patch for this in my gc, but
unless I can find out how to do a similar thing with other malloc's,
it probably won't be generally useful.

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

The swiss army knife of allocation :) This shouldn't be too difficult
to provide with scm_must_realloc, actually.
-- 
Greg