emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MPS: weak hash tables


From: Pip Cet
Subject: Re: MPS: weak hash tables
Date: Fri, 05 Jul 2024 12:08:55 +0000

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]