From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Spare memory Date: Wed, 13 Jun 2012 19:12:13 -0400 Message-ID: References: <87d353qb0v.fsf@olor.terpri.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1339629147 15887 80.91.229.3 (13 Jun 2012 23:12:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 13 Jun 2012 23:12:27 +0000 (UTC) Cc: emacs-devel@gnu.org To: BT Templeton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 14 01:12:26 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Sewje-0006JP-Rf for ged-emacs-devel@m.gmane.org; Thu, 14 Jun 2012 01:12:22 +0200 Original-Received: from localhost ([::1]:41764 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sewje-0004My-Di for ged-emacs-devel@m.gmane.org; Wed, 13 Jun 2012 19:12:22 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54047) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sewja-0004Ma-UB for emacs-devel@gnu.org; Wed, 13 Jun 2012 19:12:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SewjZ-0007fp-8c for emacs-devel@gnu.org; Wed, 13 Jun 2012 19:12:18 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:6954) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SewjZ-0007bV-4a for emacs-devel@gnu.org; Wed, 13 Jun 2012 19:12:17 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09MCqwm/2dsb2JhbABEtBGBCIIVAQEEAVYjBQsLNBIUGA0kiBwFugmQRAOjM4FYgwU X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="191340785" Original-Received: from 76-10-172-38.dsl.teksavvy.com (HELO pastel.home) ([76.10.172.38]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 13 Jun 2012 19:12:14 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 0D11F58B20; Wed, 13 Jun 2012 19:12:13 -0400 (EDT) In-Reply-To: <87d353qb0v.fsf@olor.terpri.org> (BT Templeton's message of "Wed, 13 Jun 2012 15:14:56 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:150935 Archived-At: > The `refill_memory_reserve' function (in alloc.c) is a no-op if > SYSTEM_MALLOC is defined, so the spare memory is never actually > allocated. Is this intentional? I do not really understand enough about the way we try to handle out-of-memory situations to be able to answer. > Also, why doesn't `memory_full' collect garbage immediately when memory > is exhausted? (Currently it sets `memory_full_cons_threshold', which is > checked in `Feval' and `Ffuncall'.) But I can answer this one: the GC can only be called at a few safe points, so calling it from memory_full might be unsafe. With the conservative stack scanning, we can probably safely run the GC in many more cases, but when using the GCPROs, the only safe spots are when `eval' can be called. Stefan