Re: MPS: dangling markers

[Pip Cet <pipcet@protonmail.com>]

On Saturday, June 29th, 2024 at 21:50, Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
> Ihor Radchenko yantar92@posteo.net writes:
> 
> > Eli Zaretskii eliz@gnu.org writes:
> > 
> > > > Sorry, I've asked not precisely enough. Do we know the percentage of
> > > > markers generated by that code? I mean, of the 500K markers Ihor sees,
> > > > how many could be spare?
> > > 
> > > I don't know, but a simple instrumentation (or even just a suitably
> > > defined breakpoint) will tell.
> > 
> > I looked into this. And it is near 0%. The overwhelming majority of the
> > markers are created by something else. I mostly saw save_excursion_save
> > in backtraces - it creates transient markers to save point position.
> 
> 
> Jup, it's point-marker for me. No idea who calls that so often.

It probably is save_excursion_save -- while save_excursion_restore calls unchain_marker on it when the excursion is over, that's not guaranteed to be near-immediate with the current MPS code, which searches through a potentially long vector until finding the right marker rather than finding it right away because of the LIFO list. So I think that explains why the MPS code is slower...

I think from the point of view of igc.c, it might make most sense to make BUF_MARKERS(buf) a weak hash table once we support those. I've made it a strong hash table for now, and that seems usable, but of course it would leak markers in actual long-running sessions. (Implementing weak hash tables with MPS seems quite difficult, though: you can have only one "dependent object" with strong references per object with weak references, and it cannot be in a moving pool. And since we can't resize objects that may be pinned by ambiguous references, well, the weak hash table implementation would look quite different from the strong hash tables we have).

Of course, Stefan's plan is even better :-)

Also, why does igc-info not walk the weak pool? Isn't that where the problematic markers are?

Pip