Re: MPS: weak hash tables

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Pip Cet <pipcet@protonmail.com> writes:

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

Unbelievable. Was für ein Scheiß.

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

Could happen, yes.

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

(I'm using it all the time, too. I'm running an Emacs from cl-packages
(the branch from igc is branched) to run an Emacs from the igc branch
under LLDB. The igc Emacs is what I'm using all the time, and in that I
develop in yet another branch, which I merge/rebase back to igc.)

Wrt to the merge to master, I think the maintainers, mainly Eli
probably, have to cope with the situation as it is. As far as I'm
concerned, that's solely a GNU thing.

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

Curiously enough native compilation seems to work for me now on macOS. I
was never able to debug this deep enough to find the underlying cause
why it failed. It might be a new version fo GCC 14 that I got meanwhile,
the most recent merge from master, changes in igc, or anything else.

The scanning of the byte code stack is really ugly, right. The
computation of where it ends that is. Mattias mentioned that he might
make changes in the byte code stack so that it could be marked exactly.
One could just wait till that happens. It doesn't seem to cause
stability problems.

Other than that I have nothing left in my todo list once I've done the
n-th pass of scanning the source code for untraced references  Which
proceeds slowlym but I've reached the files starting with c now :-).

> My next question would be: are there any planned big changes which
> would touch too many files on the master branch? 

Not from my side. I'm through with my stuff. Helmut mentioned interest
in remove headers from conses, I think, but I guess he can tell what he
wants to do himself better than me :-).

(I'm not interested in that, FWIW, but I can understand why some want
it.)

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

👍👍👍 :-). Thanks!

> but I may be underestimating the difficulty of getting this merged.

The administrative hurdles, you mean? Could be, no idea.