Re: MPS: out-of-memory

[Pip Cet <pipcet@protonmail.com>]

On Monday, July 8th, 2024 at 13:46, Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
> Eli Zaretskii eliz@gnu.org writes:
> > Btw, the current GC in Emacs has a feature for when Emacs runs out of
> > memory: it sets some small amount of memory aside, and uses it when
> > "memory-full" condition happens, because some memory is needed to show
> > the memory-full error message, and then shut down in an orderly
> > fashion:
> > 
> > void
> > memory_full (size_t nbytes)
> > {
> 
> ...
> 
> > See also refill_memory_reserve.
> > 
> > Do we perhaps need something like that with MPS?
> 
> 
> Yes, I think that's important, and also handling the case of getting
> errors codes from MPS in general.

I think we might want to distinguish the two cases: MPS might die, sure, but it looks like we need an out-of-memory mechanism separate from MPS to avoid assertion violations.

> As one can see, igc as a whole is in a certain state, igc_state. The
> idea is that the state changes to IGC_STATE_DEAD when something fatal
> happens. In that state, malloc is used is used for allocating Lisp
> objects instead of MPS. That lets Emacs shut down gracefully without
> entering MPS recursively as it was before I added the state.

I've seen that work, and I've seen it not work. Better than nothing :-)

> Such state changes are currently done when checking the return code of
> an MPS API function and when assertions fail.
> 
> Seems to work as expected, as I could see in a couple of backtraces from
> Ihor I believe showing the set_state (IGC_STATE_DEAD), and from my own
> experience. But maybe someone has an idea how to improve it.

If I understood Helmut correctly, he wants a mechanism to avoid thrashing after exceeding the memory limit. Maybe we need a special state for that, in which we stop the GC but continue using our memory while the user quits and goes to buy more RAM?

Speaking of memory issues in general, I'm currently seeing pure space overflows, after changes which should affect weak objects exclusively. Which is really odd, because weak objects aren't purecopied! Still investigating that one, but it's possible I'll just give up and bump pure space.

In any case, we end up segfaulting because we still try to run GC after pure space overflowed. I'll push a fix for that, but I can't promise to test the case of overflowing pure space very much.

Pip