Re: t and nil in pure memory?

[Stefan Monnier <monnier@iro.umontreal.ca>]

> #define MAYBE_MARK_OBJECT(ARG)				\
>   do {							\
>     Lisp_Object OBJ = ARG;				\
>     							\
>     if ((XTYPE (OBJ) == Lisp_Symbol))			\

Please don't use this.  Always use SYMBOLP instead.

>       {							\
> 	struct Lisp_Symbol *tptr = XSYMBOL (OBJ);	\
> 	if (!tptr->gcmarkbit)				\
> 	  mark_object (OBJ);				\
>       }							\
>     else						\
>       mark_object (OBJ);				\
> } while (0)

This may save a few function calls for some symbols, but adds a test for
all other cases, so it's unlikely to win much if anything.

I think some of the needed changes to streamline the code would be to
remove the PUREP test (i.e. just always keep the mark bit set on pure
objects instead.  This will require changing the way we handle the
markbit on strings and vectors).

Maybe we'd also want to unify the code that extracts the markbit for the
various possible objects, so that we can check the markbit before we
dispatch on the type of object we're looking at.  That would be an even
more drastic change.

> The big problem in GC is the trashing of the memory system due to
> setting/resetting and reading the mark bits...

Could be as well.  In that case, maybe we should move all the markbits
to separate bitvectors like we have for cons and floats.


        Stefan