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

Previous Next

Full log

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

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

Eli Zaretskii <eliz <at> gnu.org> writes:

> 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.

Overcommit can be disabled on GNU/Linux (the relevant knob is
vm.overcommit_memory), which will malloc return an error when there is
no more memory left on the system, thereby triggering memory_full.

malloc can also fail when it runs out of virtual memory, especially on
32-bit systems.

Previous Next

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