Re: MPS: out-of-memory

[Pip Cet]

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