Re: MPS: weak hash tables

[Gerd Möllmann]

Pip Cet <pipcet@protonmail.com> writes:

> On Saturday, July 6th, 2024 at 06:20, Gerd Möllmann 
> <gerd.moellmann@gmail.com> wrote:
>> Pip Cet pipcet@protonmail.com writes:
>> 
>> > On Saturday, July 6th, 2024 at 03:39, Gerd Möllmann 
>> > gerd.moellmann@gmail.com wrote:
>> > 
>> > > Pip Cet pipcet@protonmail.com writes:
>> > > 
>> > > > What I'm doing right now is alternating usleep(10000) and
>> > > > igc_collect() in a secondary thread. That crashes somewhat
>> > > > reproducibly in interactive sessions.
>> > > 
>> > > Could you please make that available in some form?
>> > 
>> > Sure. I was thinking about cleaning it up (usleep is non-standard) and
>> > committing it behind a stress-test option, actually.
>> 
>> Thanks! If it's not too bad performance-wise, I was thinking of running
>> it in the Emacs I'm normally using, in parallel to the rest.
>
> It is very bad since full GCs stop the main thread. However, running
> it once a second is enough to find some bugs and GCs are fairly
> fast...

Ok, thanks. I'll give it a spin when it's there. Alas, my Emacs is
already pretty slow because of of -O0 and
--enable-checking=all,igc_debug. Maybe I can trade something of that in
for the igc-collect.

> (One thing I've noticed is that MPS handles failed scans gracefully;
> we might be able to get away with "interrupting" a scan if inputs or
> signals are pending, but correctness first...)
>
>> > Right now it's dying because specpdl is a union type and GC might hit
>> > while the main thread leaves it in a partially-initialized state. I
>> > vaguely recall turning it into a struct for that reason on another
>> > branch years ago...
>> 
>> Shit. That could mean that we have to scan specpdl amiguously.
>
> I was hoping to avoid that. Maybe it's enough to just clear the pdl
> entries in between modifications, since the values we put in should be
> on the stack or in registers and be pinned.

I tried to do something in umbind_to already, which is not 100% safe I
think (there's a tiny window left, I guess).

But I find it more likely it happens in specbind, when we fill out a new
entry. Maybe we should memclr the entry there for the case that the
entry type is filled out before the rest is valid. Hm.