Re: MPS: weak hash tables

[Pip Cet <pipcet@protonmail.com>]

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

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

Pip