guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

scm_mark_dependencies & guardians


From: Han-Wen
Subject: scm_mark_dependencies & guardians
Date: Fri, 19 Jul 2002 00:14:30 +0200

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   |   address@hidden   |   http://www.cs.uu.nl/~hanwen 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]