Re: Dybvig's Guardians etc.

[Mikael Djurfeldt <mdj@nada.kth.se>]

mike@olan.com (Michael N. Livshin) writes:

> If we want to be maximally efficient, we should mark the zombies "by
> hand" in the smob mark function.  This is because we know it's a
> proper list, and so it will spare us the big switch in scm_gc_mark.

Yes, but it is really worth the effort?  There is this tradeoff
between amount of code and efficiency.  Is having lists marked faster
in guardians worth one extra loop in the guardian code?  Maybe...

> Well, what can I say? I'm lame :).

Well, I have to agree.  The fact that you didn't immediately see this
solution proves that you're the unworthiest slime of a programmer.
Go to Microsoft!  :)

> While I could do it by hand, I don't like those conventions.  Is there
> a set of GNU indent switches that does the right thing?

I don't know.  I don't use indent.  But I found this in the man page:

       In  version 1.2 and more recent versions, the GNU style of
       indenting is the default.

(BTW, I use (c-set-style "GNU") in cc-mode.)

> But there also should be this, if I'm not mistaken:
> 
>     case scm_tcs_subrs:
>         return SCM_GC8MARKP((SCM)(scm_heap_org + (((unsigned long)SCM_CAR(p)) >> 8)))

That is a bug.  Subrs don't have a GC mark.  They have eternal life.

I assume that you looked at the corresponding code in scm_gc_mark.
That code just marks the string which is the name of the subr.  It's
an optimized version of scm_gc_mark ((SCM)(scm_heap_org + (((unsigned
long)SCM_CAR(p)) >> 8))) but since we know that what is stored in the
CAR is a mangled pointer to a string, we can use SCM_GC8MARKP
directly.

In fact, we don't have to care about subrs.  If we don't do anything
about it, they will be treated as dead objects by guardians, which is
wrong.  However, if we set the GC bit in subrs (which is more
consistent, since they have eternal life) the suggested bit 2 rule
will work.

> BTW is the FIFO part really necessary?  I see two CONs:
> 1. It'll increase the size of guardian object twofold.
> 2. Depending on the collection order is losing anyway, so I don't
> see any sane use for such feature.

It's only point 1 which is a con.  That should be compared with the
real pro in Dybvig's paper: We don't need to use a critical section
in the mutator (that is, in the compiled closure).  (Remember: When we
switch to real, preemptive threading, we'll try to eliminate critical
sections.  Those which we can't eliminate will be expensive, in this
case requiring a mutex.)

I'm not sure that the user will use hundreds of guardians
simultaneously, and a malloc of 8 bytes probably takes the same time
as a malloc of 16 bytes, so I don't think we loose much by adding the
extra fields.

Regarding point 2, I agree that the order may not be important, but it
seems nice that objects come out in the order of death on the grand
scale, and in the order of calls to the guardian within sets of
objects with simultaneous death.

> thanks a lot!

I thank YOU.  If you send a new patch I'll be very happy to install it
into Guile.

/mdj