From: Eli Zaretskii <eliz@gnu.org>
To: "Mattias Engdegård" <mattiase@acm.org>
Cc: larsi@gnus.org, 54698@debbugs.gnu.org
Subject: bug#54698: non-recursive GC marking [PATCH]
Date: Mon, 04 Apr 2022 15:25:07 +0300 [thread overview]
Message-ID: <83y20ldoik.fsf@gnu.org> (raw)
In-Reply-To: <A1AD1A62-EC18-4546-968D-41C559D8104E@acm.org> (message from Mattias Engdegård on Mon, 4 Apr 2022 13:57:54 +0200)
> Feedback-ID:mattiase@acm.or
> From: Mattias Engdegård <mattiase@acm.org>
> Date: Mon, 4 Apr 2022 13:57:54 +0200
> Cc: larsi@gnus.org, 54698@debbugs.gnu.org
>
> 4 apr. 2022 kl. 13.38 skrev Eli Zaretskii <eliz@gnu.org>:
>
> > What happens with data that GC relocates, like when it relocates and
> > compacts string data? If the relocated data is allocated on the heap
> > after the simulated stack, the original string data, which is now free
> > memory, will be "trapped" behind the simulated stack, and 'free' will
> > be unable to return it to the OS. This could make the memory
> > footprint of Emacs larger than it could be.
>
> That effect is unlikely to be visible. I don't think a single (and not very big) allocation would contribute materially to heap fragmentation, given the amount of allocation being made all the time. (But prove me wrong!)
I don't need to prove you wrong: if the problem is real, we will hear
about that soon enough.
In principle, even a small allocation can prevent a large free portion
of the arena from being returned to the OS. And Lisp strings nowadays
tend to be a legion and some quite large in some applications, because
many packages abuse them (instead of using temporary buffers).
next prev parent reply other threads:[~2022-04-04 12:25 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-03 18:40 bug#54698: non-recursive GC marking [PATCH] Mattias Engdegård
2022-04-04 11:01 ` Lars Ingebrigtsen
2022-04-04 11:16 ` Mattias Engdegård
2022-04-04 11:29 ` Lars Ingebrigtsen
2022-04-04 11:31 ` Lars Ingebrigtsen
2022-04-04 11:38 ` Eli Zaretskii
2022-04-04 11:57 ` Mattias Engdegård
2022-04-04 12:25 ` Eli Zaretskii [this message]
2022-04-04 17:18 ` Mattias Engdegård
2022-04-05 1:15 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-05 8:08 ` Mattias Engdegård
2022-04-05 8:39 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-05 11:11 ` Mattias Engdegård
2022-04-05 11:26 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-05 11:43 ` Eli Zaretskii
2022-04-05 12:31 ` Philipp Stephani
2022-04-05 13:12 ` Eli Zaretskii
2022-04-06 4:09 ` Richard Stallman
2022-04-06 5:48 ` Phil Sainty
2022-04-06 10:59 ` Eli Zaretskii
2022-04-06 12:05 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-06 12:23 ` Eli Zaretskii
2022-04-06 12:34 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-06 14:10 ` Eli Zaretskii
2022-04-06 12:52 ` Lars Ingebrigtsen
2022-04-08 4:24 ` Richard Stallman
2022-04-08 5:49 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-08 6:16 ` Eli Zaretskii
2022-04-08 7:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-08 11:15 ` Eli Zaretskii
2022-04-08 11:32 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-08 11:55 ` Lars Ingebrigtsen
2022-04-08 11:58 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-08 12:07 ` Lars Ingebrigtsen
2022-04-08 12:16 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-08 13:07 ` Lars Ingebrigtsen
2022-04-09 0:28 ` Phil Sainty
2022-04-08 12:13 ` Eli Zaretskii
2022-04-04 14:32 ` Andrea Corallo
2022-04-04 14:39 ` Mattias Engdegård
2022-04-04 15:44 ` Andrea Corallo
2022-04-04 16:04 ` Mattias Engdegård
2022-04-05 9:10 ` Andrea Corallo
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83y20ldoik.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=54698@debbugs.gnu.org \
--cc=larsi@gnus.org \
--cc=mattiase@acm.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).