Re: t and nil in pure memory?

[Stefan Monnier]

>> Actually, it's even worse than that: (interned) symbols have a `next'
>> field which points to the next symbol in the obarray (hash) bucket.
>> So that's yet another reason why (pure)symbols can have pointers to non
>> pure memory.
> Can't the next pointers could be NULL.

Of course: the last symbol in a bucket has a NULL there (as do
non-interned symbols).  Can't see why that would make a difference, tho.

> Is the next pointer used for anything else other than GC?

Yes, of course: it's used for the hash-lookup done in `intern' (and
`intern-soft').

> Because if it's not, then it seems that if the next pointer was stored
> in the obarray the cache footprint of a Lisp_Symbol would be smaller.

You can remove the `next' pointer to make symbols smaller (tho on 32bit
machines it would only make them smaller if you additionally remove
another field (like plist), because of the alignment constraint).
But then you need to link all interned symbols via an (external) list,
and since most symbols are interned (AFAIK), that would end up adding
more memory than is saved.  Admittedly, it could still result in
a smaller cache footprint.  It's just far from obvious that there's much
to gain here.

I still strongly believe there's more to be gained by optimizing the
tight mark_object (recursive) loop than by trying to squeeze a few more
bytes into the purespace: once your Emacs session grows sufficiently
large, the saving of not tracing through the purespace
becomes negligible.


        Stefan