Re: gc suggestions

[Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>]

On 27 Jun 2000, Michael Livshin wrote:

>   in any case, if a Scheme-level `after-gc-hook' _is_ needed, it
>   should only be called after a GC really happened, since I hardly see
>   a user being interested whether Guile maybe considered performing a
>   GC.

I fully agree with you.  So, this clears things up about where to call the
after-gc-hook.

> * now that I think about it, one legitimate need for `after-gc-hook'
>   is to use it as the place to check or print out `gc-stats'.
>   anything else?

In the meantime I browsed a little and discovered that in popen.scm guile
checks some guardians for things that got lost in the latest gc.  To me
this seems to be a very sensible use of such a hook.  And, it just
supports your statement that the user is only interested whether a GC
really happened.

These two examples show that we will just have to live with the fact that
there exists code outside of the gc that actually belongs to the
gc.  After thinking a little bit about it I believe that it should even be
possible to work around it:  With cell access debugging in effect, the
scm_gc_async is simply not activated after _every_ gc, but, say, after
every 10000th gc or so.  This has the effect of 'simulating' a certain
gc frequency for the scheme level, although the actual gc frequency is
totally different.

> * I like your idea about a pair of C-level hooks that run before and
>   after every _possible_ GC and can influence the decision whether to
>   perform the GC at all.

OK.

> * I think that another pair of C-level hooks that run before and after
>   every _actual_ GC is also needed.  well, they already are there,
>   named `scm_gc_before_mark_c_hook' and `scm_gc_after_sweep_c_hook',
>   but I'd like to have something more GC-algorithm-independent too.

When looking at the current names, I think we should just use the existing
hooks scm_before/after_gc_c_hook and should think of new names for the
wrappers around the whole thing, like:
  scm_before_potential_gc_c_hook;
  if actual_gc {
    scm_before_gc_c_hook
    ...
    scm_after_gc_c_hook
    activate after-gc-hook async
  }
  scm_after_potential_gc_c_hook;

This should give us the necessary amount of control, while still being
clean and symmetrical.  I will prepare a patch for it.

Best regards
Dirk