Re: Do we trust the man on the GC trigger?

[Dirk Herrmann]

On 28 Aug 2001, Marius Vollmer wrote:

> I think the current interface with scm_must_malloc, scm_must_free,
> scm_done_malloc, scm_done_free is too difficult to use right and too
> hard to debug.

And, it is incomplete.  Your suggested functions scm_malloc and scm_free
provide a service that has not been available yet.

> Since the current interface is unsymmetrical (scm_must_malloc
> registers, but scm_must_free doesn't de-register), I propose to change
> it as follows.  Switching to this new interface will force us and
> everybody else to systematically review their code.
> 
>     - the smob free routine does no longer return the number of bytes
>       that have been freed.  For the transition period, free routines
>       are first encourged to return 0, then required, and then their
>       return type changes to void.
> 
>     - scm_must_malloc, scm_must_free are deprecated.
> 
>     - in their place, we have 
> 
>       Function: void *scm_malloc (size_t size, const char *what);
> 
>         Allocate SIZE bytes of memory.  When not enough memory is
>         available, signal an error.  This function runs the GC to free
>         up some memory when it deems it appropriate.
> 
>         The WHAT argument is used for statistical purposes and for
>         error reporting.  It should describe the type of object that
>         the memory will be used for so that users can identify just
>         what strange objects are eating up their memory.
> 
>       [ Note: this function will not consider the memory block to be
>         under GC control. ]
> 
>       Function: void scm_free (void *mem, size_t size, const char *what);
> 
>         Free the memory at MEM.  MEM must have been returned by
>         scm_malloc and SIZE and WHAT should match what has been passed
>         to that scm_malloc call.  MEM might be NULL in which case
>         nothing happens.
> 
>         When you don't have an accurate value for SIZE, pass 0.  This
>         is not encouraged however, as it will distort the statistics.

What kind of 'statistics' are you thinking of?  I basically see scm_malloc
as a wrapper around malloc, which - if malloc returns NULL - calls the gc
and tries malloc again.  In this case scm_free would be just for symmetry.

One could think of storing some additional data in the header of each
malloc'ed block - that's probably the reason for your WHAT argument.  
But:  why would scm_free then have to provide the size argument?  This
could be stored in such a header as well.

>       Function: void scm_gc_show (void *mem, size_t size, const char *what);
> 
>       [ Need a better name. ]
[...]
>       Function: void scm_gc_hide (void *mem, size_t size, const char *what);
> 
>       [ Need a better name. ]

scm_gc_register, scm_gc_unregister ?

> Comments?

It's definitely an improvement, and the current names (scm_must_xxx) are
just weird.  And, we've been lacking a function like your suggested
scm_malloc for some time.  Similar wrappers, btw., would make sense for
other system resources like file descriptors etc.

Best regards,
Dirk Herrmann