Re: MPS: weak hash tables

[Gerd Möllmann]

Pip Cet <pipcet@protonmail.com> writes:

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

Ah, I thought what you wrote in the other mail was related to the
IA-32 software emulation shit^Wrequirement, sorry.

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

This all gets rather complicated :-/. I'm depressed.