Re: gc.c question

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

On Mon, 29 May 2000, Han-Wen Nienhuys wrote:

> Oh, that is not what I meant. I just felt that the code was too long
> (and unreadable), and shorter code tends to be better for cache. I was
> thinking that
> 
> 
> 	 if (CASE1P)
> 	 {
> 		if (SCM_GCMARKP(ptr))
> 		   return;
> 
> 		[case-1-switch]
> 	 } else if (CASE2P)
> 	 {
> 		if (SCM_GC8MARKP(ptr))
> 		   return;
> 
> 		[case-2-switch]
> 	 }
> 
> would work just as fast, and result in smaller object code.  It's just
> that I lack the innate knowledge of GUILE's tags to think what CASE1P
> and CASE2P would be

That would be possible, but probably would CASE1P and CASE2P be fairly
complex and add another place with tight connection to the type system.

However, I think the gc is going to be modified anyway:
1)  explicit mark stacks would reduce the need for recursion during mark
2)  lazy sweeping will only look for cells to be swept when needed
3)  chunklets will extract the mark bit from the cells
4)  generational gc

The order of the above steps is probably not correct with respect to the
order in which things are going to be implemented.  However, 3 is the
interesting point with respect to your concern:  The gc bits are going to
be extracted from the objects, thus improving the separation between the
garbage collector and the type system and thus would unify the check for
an already marked object.

If I remember correctly, Michael Livshin is the one who is looking at the
gc things, based on a lot of initial work done by Greg Harvey.  Maybe
Michael is looking for helping hands with any of these tasks?  I think I
have a rough idea about point 1 and could do something about that.

Best regards
Dirk