From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Memory again Date: Tue, 06 Dec 2011 00:08:19 -0500 Message-ID: References: <4ED0F945.5090805@yandex.ru> <83pqge7syw.fsf@gnu.org> <87mxb6tkji.fsf@wanadoo.es> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1323148112 13581 80.91.229.12 (6 Dec 2011 05:08:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 6 Dec 2011 05:08:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?utf-8?Q?=C3=93scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 06 06:08:28 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RXnGU-0002kc-G5 for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2011 06:08:26 +0100 Original-Received: from localhost ([::1]:56444 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXnGT-0002wb-4F for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2011 00:08:25 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:36213) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXnGR-0002wS-4F for emacs-devel@gnu.org; Tue, 06 Dec 2011 00:08:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RXnGO-0004px-IG for emacs-devel@gnu.org; Tue, 06 Dec 2011 00:08:23 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:55856) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXnGO-0004pt-Gr for emacs-devel@gnu.org; Tue, 06 Dec 2011 00:08:20 -0500 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RXnGN-0005GW-To; Tue, 06 Dec 2011 00:08:19 -0500 In-reply-to: <87mxb6tkji.fsf@wanadoo.es> (message from =?utf-8?Q?=C3=93sca?= =?utf-8?Q?r?= Fuentes on Tue, 06 Dec 2011 05:02:09 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 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:146492 Archived-At: > From: Óscar Fuentes > Date: Tue, 06 Dec 2011 05:02:09 +0100 > > > It doesn't, or at least shouldn't. When enough memory has been > > reclaimed by GC, it should give it away to the system. At least on > > some systems, I actually see that in action, after killing a large > > buffer. > > Just for the record: a *compile* buffer ended with 10M lines of > diagnostics emitted by a compiler. The emacs process jumped from 60MB to > 526MB of RES memory. On what OS? And was the size of the buffer comparable with 520MB? > That was yesterday, and emacs keeps retaining that memory. Are you saying that you killed the *compilation* buffer and Emacs memory footprint didn't change at all? I find that hard to believe. > I guess that as the buffer grew it was reallocated again and > again. Obviously fragmentation is at play here. If ralloc.c is used on the system where you did that, fragmentation should be prevented, especially in buffer text reallocations. If ralloc.c is not used, I believe Emacs relies on the system's memory allocation to avoid fragmentation (that's why ralloc.c is not needed on those systems).