>>>>"BW" == Ben Wing <ben(a)xemacs.org>
writes:
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