From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Does Emacs return memory to the system on Mac OS X or *BSD? Date: Thu, 11 May 2017 08:33:25 +1000 Message-ID: References: <831srwbqz9.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1137aa568180c3054f330f64 X-Trace: blaine.gmane.org 1494455618 16633 195.159.176.226 (10 May 2017 22:33:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 10 May 2017 22:33:38 +0000 (UTC) Cc: Eli Zaretskii , Stefan Monnier , Emacs developers To: George Plymale II Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 11 00:33:32 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 1d8aAk-0004AX-IA for ged-emacs-devel@m.gmane.org; Thu, 11 May 2017 00:33:30 +0200 Original-Received: from localhost ([::1]:45071 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d8aAq-0005fr-3U for ged-emacs-devel@m.gmane.org; Wed, 10 May 2017 18:33:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51872) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d8aAi-0005fj-NM for emacs-devel@gnu.org; Wed, 10 May 2017 18:33:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d8aAh-0006Lr-Ta for emacs-devel@gnu.org; Wed, 10 May 2017 18:33:28 -0400 Original-Received: from mail-qt0-x235.google.com ([2607:f8b0:400d:c0d::235]:36676) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d8aAg-0006KY-CF; Wed, 10 May 2017 18:33:26 -0400 Original-Received: by mail-qt0-x235.google.com with SMTP id m91so4319912qte.3; Wed, 10 May 2017 15:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xfsJfnjy4Vqsx1zqibRO69zgDGKuzoSIXEwJ82kHR08=; b=n06bJO1kGKfTEn3fCPNi3ZKpQjCICDdXJY8MlvX5KXV/5kHAmZDR3fDi7/yy6BsYRA hamrNjqhMIzheWp0ufA2wwiZzbCkoznIf/wUUMk9dE+jDkcOypIcmzVst6Q3DEJeENFl e+xQlLlYjT9oz//g6l3b2bB4CIJqXHfGAzZdyg3iiLlZBJ2xUdlgsQVEvg4pR3Y86ghv bLbjUCBuiAxfUNgdscw8+ghcLHGx3L2DsmyJay16oOn88PXT2wLAGdS7HrBAdCG6civX YUJvxAUmDZVEZmYa/QNQtP0aAM0qhvYtkvwt1nQVuD34Gmw4RodT8nQBo6GFLK7+em6c adSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xfsJfnjy4Vqsx1zqibRO69zgDGKuzoSIXEwJ82kHR08=; b=pmAXyoAzcykOlfNb25Xu+IhxqLVj8Oj//JKZcgw2ZOEngy1UnqI9zQR9LzIVWFftOL VgR/jCrldrxKqOQOmDaAfvNDp59Tnfdk7A7ANrGw+UZaPhM2Nszm52zP1UNDZRvJSFTV n4iQQoJmA7jipiWO9UkpFb+o+DwUkqsOoZLShR0oscIL8VJfysmAQMiAGJ8SLORp5nZf jBlv8EQDvzIhSHUBEwcq4LLumbdWt7YEhvZq8Biy/91mXf4LzAig02NeyKL3LFb/gvcW Sqwxn6ChwORf3j9aGoKlbT45JjE/UgtByAMNcLnQOmVyedtlGlGsAKLVS5L/vWKFCgIK ziEg== X-Gm-Message-State: AODbwcDvPfdrXP6hLBTd7jCCb6FpvCPTCXvfXwkpB57JfOaqo/xqO54d GZtTymALJIEN7CdIeOl0ijzIrqSauQ== X-Received: by 10.200.48.44 with SMTP id f41mr892615qte.88.1494455605616; Wed, 10 May 2017 15:33:25 -0700 (PDT) Original-Received: by 10.237.62.142 with HTTP; Wed, 10 May 2017 15:33:25 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c0d::235 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:214780 Archived-At: --001a1137aa568180c3054f330f64 Content-Type: text/plain; charset=UTF-8 This may be completely off on the wrong track, but I suspect this really relates to the underlying C library implementation. I seem to remember reading (quite some time ago) about limitations on some platforms in the ability of some C libraries being able to give memory back to the operating 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. 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. On 11 May 2017 at 05:16, George Plymale II wrote: > Thanks for the specifics. That certainly helps narrow down where I > should look to find what I'm interested in. FYI, this is what I found in > `config.h' for `USE_MMAP_FOR_BUFFERS': > > /* Define to use mmap to allocate buffer text. */ > /* #undef USE_MMAP_FOR_BUFFERS */ > > There are no other occurrences of it so I guess it's not defined at all > in my build. > > -- regards, Tim -- Tim Cross --001a1137aa568180c3054f330f64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This may be completely off on the wrong track, but I suspe= ct this really relates to the underlying C library implementation. I seem t= o remember reading (quite some time ago) about limitations on some platform= s in the ability of some C libraries being able to give memory back to the = operating system. My recall is vague as it was a long time ago, but in esse= nce, 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/re= leased memory, the OS won't see that released memory until after emacs = has exited.=C2=A0

I can say that I use emacs intensively= on both Linux and OSX and run for long periods of time and certainly don&#= 39;t notice any loss of available memory or emacs growing in footprint size= .=C2=A0

On 11 May 2017 at 05:16, George Plymale II <georgie@southernohio= .net> wrote:
Thanks for the= specifics. That certainly helps narrow down where I
should look to find what I'm interested in. FYI, this is what I found i= n
`config.h' for `USE_MMAP_FOR_BUFFERS':

/* Define to use mmap to allocate buffer text. */
/* #undef USE_MMAP_FOR_BUFFERS */

There are no other occurrences of it so I guess it's not defined at all=
in my build.




--
regards,

Tim

--
T= im Cross

--001a1137aa568180c3054f330f64--