all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: 38345@debbugs.gnu.org
Subject: bug#38345: 27.0.50; Permanent increase in memory consumption after opening images (or pdfs)
Date: Sat, 23 Nov 2019 17:45:09 +0200	[thread overview]
Message-ID: <83wobqtx4q.fsf@gnu.org> (raw)
In-Reply-To: <87k17q1v0i.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> (message from Ihor Radchenko on Sat, 23 Nov 2019 23:18:21 +0800)

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: 38345@debbugs.gnu.org
> Date: Sat, 23 Nov 2019 23:18:21 +0800
> 
> What you say about Emacs not returning memory sounds like very very
> strange behaviour unless I misunderstand something. Does it mean that if
> I have emacs running as daemon and open a few hundreds of heavy pdfs
> during, say, a week, it will keep all the memory allocated for those pdfs
> (which is several Gb, at least)? If so, I don't think that Emacs should
> do it.

It depends on how the memory is allocated.  Memory allocated for
buffers gets returned to the OS when those buffers are killed.  But
memory allocated via malloc AFAIK gets grafted into the program's
address space, and when it is freed, it is left in the program's
address space, free to be used by that program for any further
allocation -- but is not returned to the system.  So if you look at
the program's address space, you will think it only ever grows,
especially if you allocate a lot of memory before releasing the first
allocation.

At least that's what I think happens on modern platforms.





  reply	other threads:[~2019-11-23 15:45 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-23 14:37 bug#38345: 27.0.50; Permanent increase in memory consumption after opening images (or pdfs) Ihor Radchenko
     [not found] ` <handler.38345.B.15745199896049.ack@debbugs.gnu.org>
2019-11-23 14:44   ` bug#38345: Acknowledgement (27.0.50; Permanent increase in memory consumption after opening images (or pdfs)) Ihor Radchenko
2019-11-23 14:48 ` bug#38345: 27.0.50; Permanent increase in memory consumption after opening images (or pdfs) Lars Ingebrigtsen
2019-11-23 15:12   ` Ihor Radchenko
2019-11-23 14:50 ` Eli Zaretskii
2019-11-23 15:18   ` Ihor Radchenko
2019-11-23 15:45     ` Eli Zaretskii [this message]
2019-11-23 16:04       ` Ihor Radchenko
2019-11-23 16:34         ` Eli Zaretskii
2019-11-23 17:33           ` Ihor Radchenko
2019-11-23 17:51             ` Eli Zaretskii
2019-11-25 16:10 ` Eli Zaretskii
2019-11-26 15:21   ` Ihor Radchenko
2019-11-26 15:55     ` Eli Zaretskii
2019-11-26 16:24       ` Ihor Radchenko
2019-11-27 21:17     ` Juri Linkov
2019-11-28  1:38       ` Ihor Radchenko
2019-11-28 12:35         ` Lars Ingebrigtsen
2019-11-28 13:11           ` Ihor Radchenko
2019-11-28 15:10         ` Eli Zaretskii
2019-11-28 17:27           ` Ihor Radchenko
2019-11-28 18:44             ` Eli Zaretskii
2019-12-02  8:04               ` Ihor Radchenko
2019-12-02 15:49                 ` Eli Zaretskii
2019-12-05  6:48                   ` Ihor Radchenko
2019-12-05 14:52                     ` Eli Zaretskii
2019-12-06  1:34                       ` Noam Postavsky
2019-12-06  7:52                         ` Eli Zaretskii
2019-12-07 19:25                           ` Noam Postavsky
2019-12-07 19:39                             ` Eli Zaretskii
2019-12-13 12:12                               ` Should use of mallopt depend on DOUG_LEA_MALLOC? (WAS: bug#38345) Noam Postavsky
2019-12-13 14:38                                 ` Eli Zaretskii
2019-12-13 15:22                                   ` Should use of mallopt depend on DOUG_LEA_MALLOC? Stefan Monnier
2019-12-13 21:55                                     ` Paul Eggert
2019-12-14  7:59                                       ` Eli Zaretskii
2019-12-16  6:18                       ` bug#38345: 27.0.50; Permanent increase in memory consumption after opening images (or pdfs) Ihor Radchenko
2019-12-16 16:30                         ` Eli Zaretskii
2020-08-02 18:14                           ` Lars Ingebrigtsen
2020-08-02 22:52                             ` Ihor Radchenko
2020-08-03  6:10                               ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83wobqtx4q.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=38345@debbugs.gnu.org \
    --cc=yantar92@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.