BW> Marcus, does this mean it's possible to allocate an array of Lisp BW> Objects (i.e. pointers, not an array of actual objects BW> themselves), with a pointer to it from a Lisp Object, and have it BW> handled properly by kkcc/mc-alloc/new-gc? This would solve many BW> of the problems of my char table. ideally, this could work BW> recursively -- you could allocate an array of pointers to arrays BW> of Lisp Objects and have new-gc and friends handle this upper BW> array as well. but even if i can do this just at the lowest BW> level, it will be a big win, since that's where most of the BW> subtables will occur. "handled properly by kkcc" means that kkcc BW> recognizes if it's seen this array before and doesn't retraverse BW> it if so. The primitives mc_alloc_array and alloc_lrecord_array do allocate an array of actual Lisp objects, not only pointers to Lisp objects, in one contiguos block of memory. This is not what you need, if I understand you correctly. You need a Lisp object that contains a fixed number of pointers to other Lisp objects. You can make your own new Lisp object for this or reuse Lisp_Vector that already has everything you need, along with an size field you probably don't need, because you have fixed-sized arrays: struct Lisp_Vector { struct LCRECORD_HEADER header; long size; Lisp_Object contents[1]; }; static const struct memory_description vector_description[] = { { XD_LONG, offsetof (Lisp_Vector, size) }, { XD_LISP_OBJECT_ARRAY, offsetof (Lisp_Vector, contents), XD_INDIRECT(0, 0) }, { XD_END } }; So the new Lisp object could leave the size out and would save one word: #define Char_Table_Size 256 struct Char_Table { struct LCRECORD_HEADER header; Lisp_Object contents[Char_Table_Size]; }; static const struct memory_description char_table_description[] = { { XD_LISP_OBJECT_ARRAY, offsetof (Char_Table, contents), Char_Table_Size }, { XD_END } }; KKCC traverses every Lisp object only once: When KKCC encounters a vector for the first time, it follows its outgoing pointers to other Lisp objects and sets the vector's mark bit. When the traversal hits the same vector again, it is not processed again, since the mark bit is set. Does this help? -- Marcus

On Tue, Nov 08, 2005 at 07:51:38AM -0600, Ben Wing wrote: If you do the allocation yourself and use an XD_BLOCK_PTR with an appropriate sized_memory_description in the Lisp Object it should work as is, even recursively. In any case, pdump handles it and it's supposed to be the picky one of the two. Multiple traversal would be a bug. Nothing would prevent a loop. OG.