Re: heads up (was: Re: Making guardians a module?)

[Dirk Herrmann]

On 28 Dec 2000, Michael Livshin wrote:

> Dirk Herrmann <address@hidden> writes:
> 
> > I have a question about your use of RECURSE:  Why are you defining it that
> > way?  For the standard scm_gc_mark, you just call scm_gc_mark.
> 
> yes.
> 
> > But, why do you try to avoid marking self-cycles in
> > scm_gc_mark_dependencies?
> 
> because self-cycles are perfectly acceptable, finalization-wise.
> 
> > First, it just does not work, because as soon as there are
> > indirections across more than one intermediate object, the root
> > object will get marked anyway.  Second, it is basically the idea of
> > the algorithm to get the root object marked if it references itself,
> > directly or indirectly.  Or am I missing something?
> 
> I'm not sure I understand the problem...  sorry if the following is
> obvious:
> 
> the idea of the algorithm is to mark all the dependencies (perhaps
> your "descendents" is actually a better term.  or maybe "successors")
> of an object without marking the object itself.  this makes sure that
> it is safe to finalize the object.  if the object references itself
> _but_ there's no other cycles, then it is safe to finalize it.

OK, I get your point.  However, I am not sure if it is really a safe thing
to do:  Can one really be sure that a directly (but not indirectly)
self-referencing object is safe to finalize?  Is it guaranteed, for
example, that a self-referencing struct can safely be finalized?  IMO,
that is a decision that the gc can not make.  Whether or not a cyclic
structure is safe to finalize depends on the semantics of the structure,
not on the question whether the cycle is 'short' (i. e. from the object
directly to itself) or longer.

Thus, I suggest to simply treat all cycles the same way.  It also has the
benefit that it simplifies the code a bit.

> note that the greedy variety is the default, and the sharing variety
> is there in case someone figures out what they are *really* useful
> for. ;)

The nice thing about the greedy guardians is, that they still fulfill
(almost, see below) the specs of the Dybvig guardians, because Dybvig's
original definition of guardians makes no guarantees that an object will
_ever_ be returned by a guardian.  That's just because of the way garbage
collection works.  Therefore, using greedy guardians does not change the
semantics of any program that up to now has used guardians.

The only difference (which I referred to above) is the impossibility to
guard an object more than once with different guardians.  However, this is
something which has not been discussed in Dybvig's paper anyway, and the
semantics are not clear either.  Thus, we don't lose much if we just
disallow it.  (If we want to allow it, we could give it a nice semantics
like:  Independent of how many times an object has been registered with
guardians, it will be retrieved at most once.  And, the object is
protected from garbage collection as long as there is at least one of the
guardians alive with which the object was registered.  While this seems to
be a clean semantics (for me, at least) it requires a lot more bookkeeping
to get right, thus it is questionable whether it is worth the effort.)

Thus, I'd vote for just kicking those sharing guardians out, until there
is a real use for them.  Otherwise we suddenly end up with the big
'backwards compatibility' problem if we once decide to drop them from the
library :-(

> > Another point: The 'trick' from eval.c to include the code itself
> > for a second compilation pass is, well, not a beautiful thing :-) It
> > may still be the best way to do things in this case.  But, if we are
> > doing things this way, shouldn't we split the code into gc.c and
> > gc.template (or whatever name) and use it as follows:
> > 
> >   /* Set up definitions for the creation of scm_gc_mark */
> >   #define <some definitions for variant #1>
> >   #include "gc.template"
> > 
> >   /* Set up definitions for the creation of scm_gc_mark_dependencies */
> >   #define <some definitions for variant #2>
> >   #include "gc.template"
> > 
> > This would allow to 'localize' the clutter, and to define something
> > like an 'interface' for the inclusion of "gc.template".  It would
> > further allow to have the corresponding function included in
> > different parts of guile: the scm_gc_mark_dependencies function for
> > example would fit better into guardians.c.
> 
> I actually agree with you.  in this case, I just went with the status
> quo, out of fear that breaking it may lead to a voluminous
> discussion. ;) but since you already started a discussion -- yes, I
> agree.  it would be nice to break up eval.c in this way too, it'd get 
> a little more readable.

If the guardians stuff has settled, and we finally come to the conclusion
that the macro-controlled template compilation is the way to go, I'd
vote for breaking up the code.  And, as you say it, eval.c is also a
candidate for such a change.

> thanks for feedback,

Thanks for your work on the guardians!

Best regards,
Dirk Herrmann