[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: scm_must_malloc() vs. malloc()

From: Gary Houston
Subject: Re: scm_must_malloc() vs. malloc()
Date: 17 Mar 2001 17:00:13 -0000

> From: Dirk Herrmann <address@hidden>
> Date: Tue, 13 Mar 2001 17:48:39 +0100 (MET)
> On Tue, 13 Mar 2001, Martin Grabmueller wrote:
> > is there any reason why fports.c uses malloc() instead of
> > scm_must_malloc()?
> Hmmm.... It seems that in this case, scm_must_malloc should be
> allright.  Maybe Gary Houston should also take a look at it.

OK, on the basis of your explanation (thanks!) I've changed them,
together with some of the allocation in ports.c, but I've got a query

> > Additionally, gh_data.c contains a lot of code like this:
> > 
> >       if (m == 0)
> >     m = (short *) malloc (n * sizeof (short));
> >       for (i = 0; i < n; ++i)
> >     m[i] = SCM_INUM (SCM_VELTS (obj)[i]);
> > 
> > I think these should get replaced by calls to scm_must_malloc too.  We
> > don't want segfaults, do we?
> These should, IMO, _not_ be replaced by scm_must_malloc.  Let me try to
> give an explanation about when scm_must_malloc should be used:  If you
> call scm_must_malloc, then you say "This memory is under garbage
> collection control".  For example, you allocate memory for some smob.  If
> the smob get's garbage collected, the corresponding memory should be freed
> by the smob's free function.  In other words, the memory that is allocated
> might be freed by garbage collection.  Guile records the amount of memory
> that is under garbage collection control.  If it becomes too much, it
> starts a garbage collection, because by collecting some unused objects,
> the corresponding memory will be freed.
> The counterexample is, if you just allocate some C level array.  No matter
> how often guile's garbage collector will be called, it won't be able to
> free that array.  Thus, that array is not under the control of the garbage
> collector.  If you allocate this array with scm_must_malloc, however, you
> fool the garbage collector.  The garbage collector might think "Hey,
> there is a lot of malloc'd memory that I might be able to collect."  Thus,
> the garbage collection would be called in situations, where there is
> actually no chance that it could free the desired amount of memory.

This doesn't seem like the whole story though: if malloc fails due to
lack of memory, there's a chance that running the garbage collector
would free some up.  So basic malloc/realloc could be improved on even
for memory not under the control of gc.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]