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

[Michael Livshin]

Marius Vollmer <address@hidden> writes:

> Hi,
> 
> I think we have a problem with the `mallocated' GC trigger.  It is not
> maintained reliably and I'm afraid we need to have everybody review
> their code to get it right.
> 
> 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.
>
> [ snip the proposal, which describes another interface.  the
> interface described is also manual, but is hopefully easier. ]

hmm.  (my "hmm"'s must be getting rather tiring lately.  sorry).

I think we have a deeper problem here.

part #1 of the problem is that somehow an implementational aspect of
the allocation scheme used in Guile was mistaken for a feature:
mainly, that all allocated entities have to have a handle (2 or 4
words) and a separately allocated data.

part #2 of the problem is that smobs are not a very nice interface,
allocation-wise.  there's no good reason for requiring the user to use
malloc & free (or scm_must_malloc/free/done_malloc/done_free) to
manage the memory of a smob.

what we end up having is requiring the user to do the bookkeeping for
us, which is neither nice nor reliable.  I'm not sure a different way
to do the bookkeeping will really help.

I think it would help to take a good look at the uses of
`scm_must_malloc' and its friends, and try to formulate better idioms.

let's try a little thought experiment.  let's pretend that smob's size
is part of the type, so there's no need for a user (or a Guile
developer, for that matter) to manually allocate and deallocate smob
data (in fact, I believe it's already the case: see `scm_make_smob').

then we are left with the following uses for malloc in Guile:

* storage for standard Scheme types (vectors, arrays, strings,
  symbols, continuations, environments, bignums, ...).  these should
  do bookkeeping, but there's no need to expose it.

* buffers, temporary areas, etc.  these shouldn't do any bookkeeping
  on behalf of the GC, since it's meaningless.

I say we should clean up our own usage of the bookkeeping functions
(not _such_ a lot to fix) and simply stop exporting them.

-- 
All ITS machines now have hardware for a new machine instruction --
SETS
Set to Self.
Please update your programs.