From: Eli Zaretskii <eliz@gnu.org>
To: "Óscar Fuentes" <ofv@wanadoo.es>
Cc: emacs-devel@gnu.org
Subject: Re: Memory again
Date: Tue, 06 Dec 2011 00:08:19 -0500 [thread overview]
Message-ID: <E1RXnGN-0005GW-To@fencepost.gnu.org> (raw)
In-Reply-To: <87mxb6tkji.fsf@wanadoo.es> (message from Óscar Fuentes on Tue, 06 Dec 2011 05:02:09 +0100)
> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 06 Dec 2011 05:02:09 +0100
>
> > It doesn't, or at least shouldn't. When enough memory has been
> > reclaimed by GC, it should give it away to the system. At least on
> > some systems, I actually see that in action, after killing a large
> > buffer.
>
> Just for the record: a *compile* buffer ended with 10M lines of
> diagnostics emitted by a compiler. The emacs process jumped from 60MB to
> 526MB of RES memory.
On what OS? And was the size of the buffer comparable with 520MB?
> That was yesterday, and emacs keeps retaining that memory.
Are you saying that you killed the *compilation* buffer and Emacs
memory footprint didn't change at all? I find that hard to believe.
> I guess that as the buffer grew it was reallocated again and
> again. Obviously fragmentation is at play here.
If ralloc.c is used on the system where you did that, fragmentation
should be prevented, especially in buffer text reallocations. If
ralloc.c is not used, I believe Emacs relies on the system's memory
allocation to avoid fragmentation (that's why ralloc.c is not needed
on those systems).
next prev parent reply other threads:[~2011-12-06 5:08 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-26 13:26 Memory again Carsten Mattner
2011-11-26 13:28 ` Carsten Mattner
2011-11-26 14:35 ` Dmitry Antipov
2011-11-26 14:48 ` Eli Zaretskii
2011-11-26 17:37 ` Dmitry Antipov
2011-11-26 20:19 ` Eli Zaretskii
2011-11-26 14:58 ` Carsten Mattner
2011-11-26 16:23 ` Eli Zaretskii
2011-11-26 19:02 ` Carsten Mattner
2011-11-26 20:31 ` Eli Zaretskii
2011-11-26 21:00 ` Eli Zaretskii
2011-11-27 10:29 ` Carsten Mattner
2011-11-27 10:43 ` Andreas Schwab
2011-11-27 13:53 ` Carsten Mattner
2011-11-27 13:11 ` Eli Zaretskii
2011-11-27 13:53 ` Carsten Mattner
2011-11-27 16:44 ` Eli Zaretskii
2011-11-27 17:37 ` Carsten Mattner
2011-11-27 17:59 ` Carsten Mattner
2011-12-06 4:02 ` Óscar Fuentes
2011-12-06 5:08 ` Eli Zaretskii [this message]
2011-12-06 9:35 ` Carsten Mattner
2011-12-06 10:24 ` Dmitry Antipov
2011-12-06 13:07 ` Eli Zaretskii
2011-12-06 13:29 ` Stefan Monnier
2011-12-06 17:20 ` Eli Zaretskii
2011-12-06 20:25 ` Stefan Monnier
2011-12-07 7:52 ` Eli Zaretskii
2011-12-07 8:15 ` Dmitry Antipov
2011-12-07 13:06 ` Eli Zaretskii
2011-12-07 14:01 ` Stefan Monnier
2011-12-08 17:30 ` Carsten Mattner
2011-12-09 3:39 ` Dmitry Antipov
2011-12-09 13:52 ` Carsten Mattner
2011-12-06 13:12 ` Eli Zaretskii
2011-12-06 16:28 ` Óscar Fuentes
2011-12-06 19:53 ` Stefan Monnier
2011-12-11 17:49 ` Nix
2011-12-15 3:52 ` Tim Connors
2011-12-15 4:09 ` Eli Zaretskii
2011-12-15 4:38 ` Tim Connors
2011-12-15 5:52 ` Eli Zaretskii
2011-12-15 4:50 ` Óscar Fuentes
2011-12-15 6:04 ` Eli Zaretskii
2011-12-16 21:55 ` Stefan Monnier
2011-12-17 17:40 ` Nix
2011-12-18 15:13 ` Dmitry Antipov
2011-12-19 1:34 ` Stefan Monnier
2011-12-19 8:28 ` Dmitry Antipov
2011-12-19 11:26 ` Stefan Monnier
2012-01-23 16:49 ` Nix
2012-01-25 16:19 ` Ted Zlatanov
2011-11-26 17:54 ` Dmitry Antipov
2011-11-26 18:47 ` martin rudalics
2011-11-26 19:09 ` Carsten Mattner
2011-11-28 4:27 ` Stefan Monnier
2011-11-28 9:24 ` Carsten Mattner
2011-11-28 15:31 ` Davis Herring
2011-11-28 21:33 ` Carsten Mattner
-- strict thread matches above, loose matches on Subject: below --
2011-12-19 19:51 emacs user
2011-12-20 5:32 ` Dmitry Antipov
2012-01-06 14:28 ` Chong Yidong
2012-01-06 15:53 ` emacs user
2011-12-20 6:34 emacs user
2011-12-20 7:43 ` Eli Zaretskii
2011-12-20 12:05 ` emacs user
2011-12-20 13:04 ` Eli Zaretskii
2011-12-20 22:07 ` Jan Djärv
2011-12-21 8:07 ` Jan Djärv
2011-12-21 10:39 ` Carsten Mattner
2011-12-21 17:55 ` emacs user
2011-12-22 14:08 ` Jan Djärv
2011-12-22 14:58 ` emacs user
2011-12-22 18:54 ` emacs user
2011-12-22 19:15 ` Jan Djärv
2011-12-23 4:41 ` YAMAMOTO Mitsuharu
2012-01-17 10:04 ` emacs user
2012-01-17 10:58 ` YAMAMOTO Mitsuharu
2012-01-17 13:14 ` emacs user
2012-01-18 1:30 ` YAMAMOTO Mitsuharu
2011-12-22 23:09 ` Carsten Mattner
2011-12-23 0:39 ` Stefan Monnier
2011-12-23 10:44 ` emacs user
2012-01-05 6:13 ` emacs user
2012-01-05 22:37 ` Jan Djärv
2012-01-06 9:58 ` emacs user
2012-01-06 11:10 ` Carsten Mattner
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=E1RXnGN-0005GW-To@fencepost.gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=ofv@wanadoo.es \
/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.