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