From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: (heap 1024 82721 1933216) Date: Sat, 18 Jan 2014 20:24:21 -0800 Message-ID: <52DB5375.5030608@dancol.org> References: <52DA8412.2080009@dancol.org> <52DB472B.5060805@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1390105471 30280 80.91.229.3 (19 Jan 2014 04:24:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jan 2014 04:24:31 +0000 (UTC) Cc: Emacs developers To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 19 05:24:39 2014 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 1W4jw7-0001l7-7G for ged-emacs-devel@m.gmane.org; Sun, 19 Jan 2014 05:24:39 +0100 Original-Received: from localhost ([::1]:45103 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4jw6-0002xw-QU for ged-emacs-devel@m.gmane.org; Sat, 18 Jan 2014 23:24:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38677) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4jvy-0002fs-3v for emacs-devel@gnu.org; Sat, 18 Jan 2014 23:24:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W4jvr-0002Vf-Sr for emacs-devel@gnu.org; Sat, 18 Jan 2014 23:24:29 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:48458) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4jvr-0002VX-FK for emacs-devel@gnu.org; Sat, 18 Jan 2014 23:24:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=L/HIvmpMh5FDdYYPtylPjJKf4Z7lX+T0qxdnL1f4PQo=; b=qqE9us1UduMGSMdYliFLA/BMp9L+8LeMw+i6pNLTXM/MtFQ19e5IN4ZBcWuzhoPyZDcEoyvB6f/2vUKZcH+JXwrFBohlNm1dBqFB5h6ltK7Bia19coArl/4Jha4G772XmUHXAueEggHC+Qaf/dkwKVKll5PXrEcOkKUH6SCgQYbqu1IKGoA+iMfBX5iPawVuczYTK13l5wwHZ0jQTDqG0BzH2AzrFJTz5ofkakJD+lS4I42Ju0hvDqp1ji0WaV3eLGV4PjJ7Z7QH2x6Tr6HDe/97c/uyFVQj2cmCey/vrFFRC1cP/pUtNDWlHVyFlqQuO+KZ3GaaJmhjdG2klbvK3w==; Original-Received: from c-76-104-210-106.hsd1.wa.comcast.net ([76.104.210.106] helo=[192.168.1.50]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1W4jvq-00031a-Vb; Sat, 18 Jan 2014 20:24:23 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:168718 Archived-At: On 01/18/2014 08:19 PM, Stefan Monnier wrote: >>> Could be. For an Emacs that grew to 6GB, I don't find it worrisome >>> if it doesn't shrink back below 2GB. > [...] >> Longer-term, it would be nice to be able to compact objects. We could move >> objects during the unmark phase of GC by looking for forwarding pointers to >> new object locations. (Of course, objects found through conservative >> scanning would have to be considered pinned.) > > Lots of work for *very* little benefit. I've pretty much never seen > a case where a user is really annoyed just by Emacs's size "after > freeing everything". In pretty much all cases, the user was already > annoyed at Emacs's size *before* freeing everything, so that's the > problem to solve. Once this problem is solved, the fact that the memory > is not very much returned to the OS is usually not a problem any more. At the very least, we can add internal fragmentation statistics to the return value of Fgarbage_collect. And FWIW, I've heard complaints about Emacs using too much memory and never returning it to the system. >>> I'm much more worried about: how on earth did it grow to 6GB? >> I have no idea --- I was just doing normal editing over a few dozen files. > > Yet, *that* is the problem. The fact that freeing everything didn't let > you work around this problem is of very little concern. > > So if you ever bump into such a situation, don't bother trying to free > stuff, and instead try and figure out what is eating all that memory. That's a separate issue. Regardless of other concerns, the malloc heap should never get this fragmented.