Re: [PATCH21.5] Asynchronous finalization revised and merge of MC_ALLOC and NEW_GC

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 arrays. 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. -- Marcus