scm_mark_dependencies & guardians

scm_mark_dependencies & guardians

[Han-Wen]

hi all,

Strolling through gc.c, I found a construct worthy of
Spaghetti-coding 101, namely


	#define MARK scm_gc_mark
	#define FNAME "scm_gc_mark"

	#endif /*!MARK_DEPENDENCIES*/

	/* Mark an object precisely.
	 */
	void
	MARK (SCM p)
	#define FUNC_NAME FNAME
	{
		:
	#ifndef MARK_DEPENDENCIES
		:

	/* And here we define `scm_gc_mark_dependencies', by including this
	 * same file in itself.
	 */
	#define MARK scm_gc_mark_dependencies
	#define FNAME "scm_gc_mark_dependencies"
	#define MARK_DEPENDENCIES
	#include "gc-mark.c"
	#undef MARK_DEPENDENCIES
	#undef MARK
	#undef FNAME

The scm_gc_mark_dependencies function is used once, to detect if a
guardian object points to itself in any way. I would like to change
this code to be like

       inline
       scm_mark (SCM p)
       {
         if (marked_p(p))
	    return
	 mark_cell (p)
         scm_mark_dependencies (p)
       }      

       /* mark all objects pointed to by P */
       inline scm_mark_dependencies (SCM p) 
       {
	..

       }

however, the current code is so obtuse (goto considered harmful) that
it is difficult to make out what the exact semantics of
scm_mark_dependencies () should be. For example, a self-reference to
the argument of scm_mark_dependencies() is not followed or marked, but
only in when such a mark happens in scm_mark_dependencies(), not if it
happens in subsequent recursive invocation of scm_gc_mark().

Any comments?  Any objections if I change the code as I proposed?  I
am a little worried that the above code may be less efficient due to
less use of goto, but that is something that can be measured.

(Some minutes later: I implemented the change, and measured a 0.4 %
speed decrease in one particular GC benchmark. I'd say that 0.4% is
not worth the spaghetti, if it were statistically significant. There
are no errors from the test suite.)


-- 
Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: scm_mark_dependencies & guardians

[Marius Vollmer]

Han-Wen <hanwen@cs.uu.nl> writes:

> Any comments?  Any objections if I change the code as I proposed?  I
> am a little worried that the above code may be less efficient due to
> less use of goto, but that is something that can be measured.

I don't want to comment on the big picture, just one note: it is
important that marking is done in a 'tail calling' way.  That is, we
must not recurse when marking the spine of a list, for example.  That
is the reason for the goto in gc_mark.

> (Some minutes later: I implemented the change, and measured a 0.4 %
> speed decrease in one particular GC benchmark. I'd say that 0.4% is
> not worth the spaghetti, if it were statistically significant. There
> are no errors from the test suite.)

Hmm, I don't think we should fear goto.  Sometimes it is clearer to
use goto than it is to avoid it.  The main spaghetti in gc.c is the
inclusion in itself.  What about moving the marking code into a
separate file and including it twice?  We already do this for
num2float and num2integral.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: scm_mark_dependencies & guardians

[Han-Wen Nienhuys]

mvo@zagadka.ping.de writes:
> I don't want to comment on the big picture, just one note: it is
> important that marking is done in a 'tail calling' way.  That is, we
> must not recurse when marking the spine of a list, for example.  That
> is the reason for the goto in gc_mark.

Sure, otherwise you get stack overflow.

> Hmm, I don't think we should fear goto.  Sometimes it is clearer to
> use goto than it is to avoid it.  The main spaghetti in gc.c is the
> inclusion in itself.  What about moving the marking code into a
> separate file and including it twice?  We already do this for
> num2float and num2integral.

I already recoded it without inclusion. You can get around including a
file twice by doing

	mark (SCM p)
	{
	   if (marked(p)) return;
	   set_mark(p);
	   mark_dependencies (p);
	}

	mark_dependencies(SCM p)
	{
	again:
		switch (tag(p))
		{

		   .... // lots of cases jumping to mark_next

		}
		
		return;

	mark_next:

	   if (marked(p)) return;
	   set_mark(p);
	   goto again;

	}


-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl    | http://www.cs.uu.nl/~hanwen/


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel