This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gc suggestions


Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:

> So what is the fix then?  Currently we have:
> 
> * scm_before_gc_c_hook is run _before_ scm_block_gc is tested.  Thus, it
>   seems that it was intented to allow scm_before_gc_c_hook to set
>   scm_block_gc to inhibit gc.  However, scm_after_gc_c_hook is _not_ run
>   if scm_block_gc is set.  This is asymmetrical.
> * after-gc-hook is always run, even if scm_block_gc is set.
> 
> The problem is, that I think it is a good idea to have a pair of C
> level hooks that are called as wrappers, even if there is no gc in
> between.  This could be the role of the current scm_before_gc_c_hook and
> scm_after_gc_c_hook.  In any case these should be called symmetrically.
> But probably these should be renamed to something else in order to avoid
> confusion with the scheme level after-gc-hook.

let's look at the situation with user's eyes (as much as we can):

* one way to look at hooks is "stuff to run when something interesting 
  happens".

* what can be interesting about GC from a Scheme programmer's POV?
  [s]he would like to know about the memory performance of the program
  (there is the `gc-stats' primitive, and it could be somewhat
  improved too, but that's beside the point).  does [s]he need to know
  _when_ a GC happened and have a procedure run at _that_ _precise_
  _moment_?  I don't know, but I doubt it.  (people should chime in at
  this point saying "you are wrong, I need it for this and that!").
  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.

* 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?

* 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.

* 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.

> As I have mentioned, in the context of cell access debugging when
> triggering intermediate gc's, it is problematic if the gc causes
> code to be performed outside of the scope of the gc itself.  This is
> the case with after-gc-hook, since it is performed as an async as
> soon as the gc has finished.
> 
> So, what do you think?

this is a hairy issue.  in fact, I believe it was already discussed at 
length here -- it's probably a good idea to check the archives.

-- 
Tools that are no good require more skill.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]