This is the mail archive of the
mailing list for the Guile project.
Re: Again: Guile + Boehm's gc
> Khimenko> No. You can use your standard system malloc and Boehm's
> Khimenko> GC.
> Only if you don't mind your programs being GC aware. I thought the
> whole point of this excercise is to make sure applications are not GC
There are different levels of GC awareness, applications might have to
make some small effort for GC but providing the rules are simple
with minimal exceptions, no one is going to be bothered.
> I have. I wasn't making an idle speculation. Mixing malloc and
> GC_malloc is a recipe for memory leaks. Consider the case of a user
> smob. You need to use GC_malloc on top of the current smob system,
> and you need to make sure that malloc isn't used incorrectly.
Well you could tell the smob writer to always use GC_malloc inside
the smob -- that would solve a lot of problems, except when the smob
is designed to encapsulate some stuff that was already written using
malloc and the author doesn't want to change everything over.
Providing there is a way for the smob author to be able to hook the
destruction of a smob to their own function there would be no problem
using malloc inside the smob... most C programmers are already very
comfortable with keeping track of resources (especially memory) so
they won't be bothered remembering to call free() on what they have
What does bother application programmers is when they have done what
seems to be the right thing and it still fails. For example:
void floodle( char *p )
q = malloc( strlen( p ) + 18 );
if( !q ) return;
sprintf( q, "(define floodle %s)", p );
gh_eval_str( q );
free( q );
Many people would feel they are pretty good with memory handling
and have a reasonable idea about garbage collection but not be able
to figure out why this can memory leak. With smobs it gets even more
complicated because there are times when you might want to change
links to memory lists inside an smob. I guess there are lots of
major applications out there with minor memory leaks and that doesn't
seem to reduce their popularity <shrug> so maybe this is no big deal.
This sort of a thing gets to be more of a problem if you are running
untrusted code where someone might TRY to exploit the weakness in
your code (e.g. suppose you want to provide guile scripting in a web
browser, admittedly an unlikely project but not to be completely
discounted, and you visit a page that brings down your browser).
> Khimenko> The only rule is to NOT use free for memory
> Khimenko> obtained via normal malloc (pretty obvious: free from
> Khimenko> system library will not know what to do with object
> Khimenko> allocated with GC_malloc).
> This is exactly the point about "special rules". You've traded a
> system where you must remember not to place certain opaque types into
> a global variable for a system where you have to remember which
> pointers are malloced by which routine.
Guile has a few more caveats than just the global variable limitation.
> If you use the wrong free, it
> creates a bug that is *extremely* difficult to track down.
Actually, I suspect you would be looking at a crash in the free itself
or else in a malloc very soon afterwards. As memory allocation debugging
goes, there are much more elusive bugs than this. For example, you
want to read chars from a scheme ``port'' in a C function. If you malloc
up buffer space then you cannot safely call scm_getc( port ) because you
don't know if there might be something wrong with ``port'' (I guess there
might be ways of checking everything that could possibly go wrong with
port but that is too painful). Thus, you must use a scheme string as
buffer space rather than a malloced string. Thus you need SCM_CHARS()
to get internal access to the string space... which is no big deal if you
have used a ``volatile'' in the right place, if you haven't well then
you have a properly elusive bug which is plenty harder to track down
than a bad call to free() (speaking as someone who has tracked down both).
Aside from that, there is no reason (in principle) why you cannot provide
a generic GC_free() for the application writer which can handle BOTH types
of memory. After all, the GC mechanism must know what it owns, so if it
gets something that it does not own then it must belong to someone else,
thus it gets passed on to the standard free(). I'm not sure if Bohem's
code can do this but it must be POSSIBLE even though it may result in a
bigger performance hit (I'm sure that Bohem allocates in chunks so scanning
the chunk list should be no big deal).
And I agree that getting a good module system into place has a higher
priority than fixing the GC quibbles. Come to think of it, thinking of
an exception and continuation system that is compatible with typical C
program mentality would also be nice but I think that is asking for the