From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Carsten Mattner Newsgroups: gmane.emacs.devel Subject: Re: Memory again Date: Sat, 26 Nov 2011 15:58:49 +0100 Message-ID: References: <4ED0F945.5090805@yandex.ru> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: dough.gmane.org 1322319539 24346 80.91.229.12 (26 Nov 2011 14:58:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 26 Nov 2011 14:58:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 26 15:58:55 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 1RUJiR-0000Wf-LL for ged-emacs-devel@m.gmane.org; Sat, 26 Nov 2011 15:58:55 +0100 Original-Received: from localhost ([::1]:40080 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUJiQ-0007N3-Pr for ged-emacs-devel@m.gmane.org; Sat, 26 Nov 2011 09:58:54 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:48364) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUJiN-0007Mn-Sl for emacs-devel@gnu.org; Sat, 26 Nov 2011 09:58:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RUJiM-0003II-Qu for emacs-devel@gnu.org; Sat, 26 Nov 2011 09:58:51 -0500 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:39522) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUJiM-0003IC-M1 for emacs-devel@gnu.org; Sat, 26 Nov 2011 09:58:50 -0500 Original-Received: by iaek3 with SMTP id k3so7907372iae.0 for ; Sat, 26 Nov 2011 06:58:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QcqcXaC+Gevwhk1UYS8Z+tSRXvEUYXlKTp10eJbeP0E=; b=Ip3Y3mdgISixOBeG/AaIPtmkNLmHL1pHP1bpzm2xL/Pbd5ITdMYVpVmYtjd6So3Epv lxYatX8Q+yEGWqUbfeqBFsxNqeQSpVgaYC27WDhBY6FKsxFYHPtBK+lWeyhvakSH8r/g jucaImipfBWVzvUgE0y+5mx6FUxD3bGZhe2NU= Original-Received: by 10.50.242.103 with SMTP id wp7mr46386002igc.21.1322319529638; Sat, 26 Nov 2011 06:58:49 -0800 (PST) Original-Received: by 10.50.190.167 with HTTP; Sat, 26 Nov 2011 06:58:49 -0800 (PST) In-Reply-To: <4ED0F945.5090805@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.169 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:146261 Archived-At: On Sat, Nov 26, 2011 at 3:35 PM, Dmitry Antipov wrote: > On 11/26/2011 05:26 PM, Carsten Mattner wrote: > >> After having used 4 erlang-mode buffers and having killed all buffers >> for more than an hour and having run M-x garbage-collect there still >> seems to be unreclaimable space. > > This is an internal heap fragmentation, the most common disadvantage > of simple mark and sweep GC. Allow me to be naive and ask this: what about compaction? Would the allocator in use fragment the overall system memory space if it frees more aggressively? Does emacs fear the memory may be used by someone else and hold onto what it claimed? Half-joking, half-serious asking. >> It's been sitting there with 0 buffers in *scratch* at around 54megs >> for a couple hours. > > Try to restore your 4 erlang-mode buffers and other stuff which has been > previously used to reach 54M. If the heap will not grow substantially > beyond 54M, this means that fragmented space was mostly re-used. > If you ends up with 2x or more heap, there is a serious memory leak > somewhere. Nothing like that happened, but I had to restore some of the files as it was from a temporary directory. Restoring the directory made emacs realize the "file has changed on disk". Is this checked via a hash/checksum or does emacs carry along more than that? Details: before I opened the same buffers as good as I remembered it was at 55megs up from 54.2megs (approx.) and it went up .4megs.