From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Does Emacs return memory to the system on Mac OS X or *BSD? Date: Wed, 10 May 2017 20:06:05 -0400 Message-ID: References: <831srwbqz9.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1494461209 5456 195.159.176.226 (11 May 2017 00:06:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 11 May 2017 00:06:49 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: Eli Zaretskii , George Plymale II , Emacs developers To: Tim Cross Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 11 02:06:45 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d8bcx-0001Gl-0t for ged-emacs-devel@m.gmane.org; Thu, 11 May 2017 02:06:43 +0200 Original-Received: from localhost ([::1]:45264 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d8bd2-0003Bk-FZ for ged-emacs-devel@m.gmane.org; Wed, 10 May 2017 20:06:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d8bcS-0003Bd-QO for emacs-devel@gnu.org; Wed, 10 May 2017 20:06:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d8bcR-0006z4-Sl for emacs-devel@gnu.org; Wed, 10 May 2017 20:06:12 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:4361) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d8bcO-0006uP-1c; Wed, 10 May 2017 20:06:08 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CjAgC8qRNZ/3Z8oWxdGgEBAQECAQEBAQgBAQEBg1VChEeLWZBlKwGXVYYeBAIChQFDFQECAQEBAQEBAWsohRYBBAFWIwULCw4mEhQYDSSKLAi0TYp1AQEIAiaLWIpRBZ4KjX2HO4hVhnmSf4FENSKBCi8gCC6HVySJTwEBAQ X-IPAS-Result: A0CjAgC8qRNZ/3Z8oWxdGgEBAQECAQEBAQgBAQEBg1VChEeLWZBlKwGXVYYeBAIChQFDFQECAQEBAQEBAWsohRYBBAFWIwULCw4mEhQYDSSKLAi0TYp1AQEIAiaLWIpRBZ4KjX2HO4hVhnmSf4FENSKBCi8gCC6HVySJTwEBAQ X-IronPort-AV: E=Sophos;i="5.38,321,1491278400"; d="scan'208";a="312539020" Original-Received: from 108-161-124-118.dsl.teksavvy.com (HELO ceviche.home) ([108.161.124.118]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 May 2017 20:06:05 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 1F2D4662CE; Wed, 10 May 2017 20:06:05 -0400 (EDT) In-Reply-To: (Tim Cross's message of "Thu, 11 May 2017 08:33:25 +1000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:214782 Archived-At: > system. My recall is vague as it was a long time ago, but in essence, while > an app can release memory it no longer requires, that memory is not > actually released back to the OS to be used by other apps until the app has > exited. The upshot is that while the app i.e. emacs, may have > freed/released memory, the OS won't see that released memory until after > emacs has exited. Indeed. And in practice it makes very little difference: this freed memory, by its very nature, will not be accessed by the application, so it will naturally end up swapped to disk if memory pressure requires it. IOW the only difference is in the fact that it requires more swap space, which can occasionally be noticeable, e.g. when you don't have swap space at all. > I can say that I use emacs intensively on both Linux and OSX and run for > long periods of time and certainly don't notice any loss of available > memory or Emacs growing in footprint size. Since this "unreturned freed memory" is free and hence available for reuse, it cannot cause excessive *growing* of a process. It can only cause a lack of shrinking, which is why it rarely matters. Excessive growth ("excessive" in the sense that it eats more memory than what is actually used) is usually caused by things like leaks or fragmentation, which are different issues. Stefan