Re: MPS: weak hash tables

[Pip Cet <pipcet@protonmail.com>]

On Friday, July 5th, 2024 at 03:50, Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
> Pip Cet pipcet@protonmail.com writes:
>
> > > Ah, I thought what you wrote in the other mail was related to the
> > > IA-32 software emulation shit^Wrequirement, sorry.
> >
> > It's both:
> >
> > 1. change the IGC header to be a uint64_t, because bitfields don't always behave as expected.
> > 2. use the low-order bits to distinguish extended external extra dependency headers from ordinary one-word headers. (This fixes the remaining IA32 bug)

Except that a uint64_t is two 32 bit words, and they both must be non-aligned. How horrible. At least we've excluded WIDE_EMACS_INT :-)

> Honesty demands that I add that that would also be good for me: I said
> right from the start that I won't maintain anything and lately that I
> really really feel I need to have a break from this MPS stuff, so I'd
> love if you could take over and realize yoiur ideas.

My priority would be getting the branch merged. If it isn't, it'll bit-rot, I'm afraid. I realize it's too soon to ask for a final decision on that (which would be made on merge day, presumably), but I've found myself using my IGC emacs -Q when my vanilla Emacs is stuck in GC, so it's not like it doesn't work at all. And, yes, I realize there's a lot of work to be done for that...

Feature/bug-wise, what's still missing? key-or-value weakness (haven't slept enough yet to decide whether to merge), sure, but is that essential? The signal handler stuff is fixable, I'm convinced. I've got a bug fix for what I hope to be the very last bug with the IA-32 stuff. There are two very minor bugs (there are Lisp_Objects in the wrong part of pure space, and igc_realloc_ambig doesn't park the arena--one-liners really). The two major fixmes concern native compilation and the byte code stack, right? I'm perfectly happy to leave unnecessarily ambiguous references ambiguous for now.

My next question would be: are there any planned big changes which would touch too many files on the master branch? The one I can think of is I would like to move the IGC header to live in struct Lisp_Cons/Lisp_String/Lisp_Symbol/Lisp_Float and in union vectorlike_header, and make client == base. I believe this would also make things easier for other GC approaches which would also need some sort of header. No real problem for non-native-comp builds: the problem with this is changing these structs requires adjusting comp.c, which rebuilds them in libgccjit calls. I don't think that's very hard to do either, but it's potentially subtle and I'm planning to write Andrea about it.

So, yes, I'd love that too, but I may be underestimating the difficulty of getting this merged.

Pip