Re: MPS: weak hash tables

[Pip Cet <pipcet@protonmail.com>]

On Thursday, July 4th, 2024 at 07:17, Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
> > > Move fast and break things. Normal.
> > 
> > I'm afraid I've continued to do so. After the last push,
> 
> Did that too yesterday for --enable-checking. and had to revert now :-)

> > my TODO list is down to:
> > 
> > * fix bugs that slipped through (well, obviously)
> > * user-defined hash table tests for weak tables don't work
> > * key-or-value weakness doesn't work

I believe we can make key-or-value tables work, and gain a potentially useful debugging aid, by allowing struct igc_header to contain a tagged pointer to an extended "header" structure which resides in external (non-MPS) memory (a "remote reference" in MPS speak, which is usually forbidden in AMC pools but appears to work if it's non-MPS memory); we'd use the extended header instead of the header word to determine object size, hash, and object type. That extended header could then contain a Lisp_Object which would be scanned and kept alive while the object belonging to the header is allocated, not just while it's still reachable.

So if we (puthash a b key-or-value-hash), we'd make `a' keep alive `b' and vice versa, but once they're no longer strongly reachable from other objects, they'd be collected. (I've tried this, it works).

And we could finalize objects appearing in weak hash tables.

This would cause some memory fragmentation (xmalloc isn't moving), but I don't think that's much of an issue: if you're using exotic weak hashes, you're already creating unmovable allocations in weak_hash_pool; if you're debugging, you probably don't care.

However, the functional gains are minimal and so far no one has demanded key-or-value hashes...

> I'm making another pass over C files in alpabetical order, trying to
> find untraced references. At the source file I'm using (no Gtk and so
> on). Now at buffer.c, and I think I see one.

Good luck!

Pip