GNU bug report logs - #54698
non-recursive GC marking [PATCH]

Previous Next

Full log

Message #79 received at 54698 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: luangruo <at> yahoo.com, mattiase <at> acm.org, p.stephani2 <at> gmail.com,
 54698 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#54698: non-recursive GC marking [PATCH]
Date: Wed, 06 Apr 2022 13:59:08 +0300

> From: Richard Stallman <rms <at> gnu.org>
> Cc: p.stephani2 <at> gmail.com, luangruo <at> yahoo.com, mattiase <at> acm.org,
> 	larsi <at> gnus.org, 54698 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.