bug#54698: non-recursive GC marking [PATCH]

[Eli Zaretskii <eliz@gnu.org>]

> From: Richard Stallman <rms@gnu.org>
> Cc: p.stephani2@gmail.com, luangruo@yahoo.com, mattiase@acm.org,
> 	larsi@gnus.org, 54698@debbugs.gnu.org
> Date: Wed, 06 Apr 2022 00:09:25 -0400
> 
>   > > I think this is just how modern OSes behave: they will happily hand
>   > > out arbitrary amounts of memory and then kill processes without
>   > > warning if they use too much memory. By design, there's nothing these
>   > > processes can do about that.
> 
>   > That's not my experience.
> 
> A few weeks ago, when I had too little physical memory for a while,
> I found that my machine would start thrashing, and then Linux would
> kill a large process.  Fortunately that was IceCat, not Emacs.
> A wizard told me it was indeed killing processes without warning,
> but at that moment the thrashing process had no way to receive or
> act on a warning.

You seem to be saying that Emacs on GNU/Linux cannot reliably detect
that it's approaching the memory limit, or have already approached it.
That'd be sad if it were indeed 100% true, and couldn't be alleviated
by some system setting.  (I thought one could use "ulimit -v"?)  Or
maybe Emacs should have its own setting for how much memory is
available, if it can reliably tell how much is being used.

If indeed this cannot be solved on GNU/Linux, it is IMO sad, because
on MS-Windows I was saved several times by memory_full and what's
behind it, when I occasionally needed to visit very large files that
exceeded my system's capacity for Emacs.