Re: MPS: dangling markers

[Pip Cet <pipcet@protonmail.com>]

On Monday, July 1st, 2024 at 04:22, Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
> Pip Cet pipcet@protonmail.com writes:
> 
> > On Sunday, June 30th, 2024 at 19:22, Gerd Möllmann gerd.moellmann@gmail.com wrote:
> > 
> > > Thanks! What do youo think about making a patch containing only your
> > > weak hash tables, and leaving the BUF_MARKERS alone for now?
> > 
> > I think that's the best way forward. Patch attached.
> 
> Could you please send me something from git format-patch? That way I'd
> have commit message and your authorship would also be clear. Or even
> better, if you have the rights could you please commit to the branch?

I'll do that. Please let me know what I got wrong.

> > > That way
> > > igc could support the existing uses of weak hash tables (I remember one
> > > in the CLOS department somehwere), and they would be somewhat tested.
> > > Don't remember if we have unit tests for them.
> > 
> > It seems MPS isn't very eager about splatting weak references during
> > ordinary automatic GC, FWIW. What I'm observing with
> > 
> > (while t
> > (dotimes (i 10000)
> > (puthash (cons 1 2) (cons 3 4) table))
> > (message "%S" (hash-table-count table))
> > (sit-for 0.1))
> > 
> > is that the hash table starts out at 0, grows quickly, resets to
> > count=0 once, then keeps growing and never splats any references after
> > that. It's quite possible this is a bug in my code, of course.
> 
> Yes, it's not eagerly splatting. Don't know. Which reminds me that I
> wanted to look if the AWL pool maybe has some paramter that one could
> set, or something else influences that, like the mortality rate of the
> generation chain. Or something completely different.

I debugged this a little, and it turns out that when we alternate between two weak hash tables, splatting works fine. It seems that if MPS receives a SIGSEGV in a segment belonging to a weak hash table, it scans it in "exact" mode, not "weak" mode, in order to continue execution as soon as possible. That's how I read this comment in mps/trace.c:

 * If the trace band is EXACT then we scan EXACT. This might prevent
 * finalisation messages and may preserve objects pointed to only by weak
 * references but tough luck -- the mutator wants to look.

So I don't think this will be a problem in practice...

Pip