>>>>"sjt" == Stephen J Turnbull
sjt> I guess this is OK with me. The only
thing is that USE_KKCC by
sjt> itself doesn't seem to enforce Lisp-ification of structs
sjt> containing Lisp_Objects.
No, it does not. USE_KKCC only touches the mark algorithm: Instead of
calling each object's mark method, it uses memory descriptions
(formerly known as pdump descriptions) to identify outgoing pointers.
sjt> But that seems pretty desirable to me, especially after my
sjt> adventure into the syntax cache last week. It would be nice if
sjt> we had a tag that (somewhat) corresponded to that. Will NEW_GC
sjt> play the same role?
I don't get what you mean. What role do you refer to?
sjt> BTW, are there any real downsides to Lisp-ification of such structs?
They all get an lrecord_header, so there is a memory overhead. But it
makes the code much simpler and easier to maintain. I thought of
removing conditionalization on these parts of NEW_GC, but I haven't
done yet because the old allocator has no way to allocate arrays of
Lisp objects. This is needed for example by hash tables and dynamic
Lisp arrays. Many of the new Lisp objects are based on Lisp object
sjt> I'd like to release a checkpoint beta before you commit this. I'll
sjt> start on that later tonight my time. Once you see the r21-5-25 tag on
sjt> version.sh in CVS, it's OK to commit. (I thought abouut just tagging
sjt> and making a branch if necessary, but that doesn't quite work the
sjt> release heralds won't get into the ChangeLogs in the right places.)
I wait till Monday or longer, no need to hurry.
sjt> Once the beta is out, maybe we can consider enabling NEW_GC by default
sjt> for a couple of weeks. I really don't see why people who are
sjt> explicitly selecting the bleeding edge shouldn't bleed a little. :-)
Sure, I'm up for it.