unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Po Lu <luangruo@yahoo.com>
To: Lynn Winebarger <owinebar@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
	 Stefan Monnier <monnier@iro.umontreal.ca>,
	 emacs-devel@gnu.org
Subject: Re: Loading tramp for dump goes into infinite regress
Date: Tue, 09 Aug 2022 20:36:04 +0800	[thread overview]
Message-ID: <87fsi5zj9n.fsf@yahoo.com> (raw)
In-Reply-To: <CAM=F=bCe2ZW5TcL+OH09V2DP=UfzU870Xoy=fEw+vFUVFUmd8Q@mail.gmail.com> (Lynn Winebarger's message of "Tue, 9 Aug 2022 08:29:13 -0400")

Lynn Winebarger <owinebar@gmail.com> writes:

> The second statement was comparing dumped versus undumped performance,
> whether native- or byte- compiled.  This isn't a novel observation,
> but the dump is basically a one-shot mark-compact GC collection, and
> the mmap'ed pdump files would ideally be treated like the old
> generation of a generational collector, and so not traced in most (or
> all) collection cycles.  This is (or should be) one benefit of pure
> space, although the requirement that it be read-only could be dropped
> as long as the write-barrier remains and is used to record any
> inter-generational pointers to a root set traced by the collector.

This (very) minor benefit of pure space is already gone, since it is
unprotected and scanned normally for garbage collection in pdumper
builds.



  reply	other threads:[~2022-08-09 12:36 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-24  0:47 Loading tramp for dump goes into infinite regress Lynn Winebarger
2022-07-24  7:55 ` Michael Albinus
2022-07-24 12:05   ` Lynn Winebarger
2022-07-24 12:23     ` Eli Zaretskii
2022-07-24 13:30       ` Lynn Winebarger
2022-07-24 13:34         ` Eli Zaretskii
2022-07-24 14:05           ` Lynn Winebarger
2022-07-24 14:09             ` Eli Zaretskii
2022-07-24 14:28               ` Lynn Winebarger
2022-07-24 16:00             ` Lynn Winebarger
2022-07-24 16:20               ` Lynn Winebarger
2022-07-24 16:31                 ` Eli Zaretskii
2022-07-25 12:49                   ` Lynn Winebarger
2022-07-25 13:56                     ` Eli Zaretskii
2022-07-26 11:24                       ` Lynn Winebarger
2022-07-27  0:58                         ` Lynn Winebarger
2022-07-27  2:48                           ` Lynn Winebarger
2022-07-27  8:31                             ` Lynn Winebarger
2022-08-09 12:29                       ` Lynn Winebarger
2022-08-09 12:36                         ` Po Lu [this message]
2022-08-09 13:22                           ` Lynn Winebarger
2022-08-09 13:42                             ` Po Lu
2022-08-09 15:55                               ` Lynn Winebarger
2022-07-25 16:54                     ` Stefan Monnier
2022-07-25 17:05                       ` Stefan Monnier
2022-07-26  0:28                       ` Lynn Winebarger
2022-07-26  1:10                         ` Lynn Winebarger
2022-08-06  6:07                       ` Lynn Winebarger
2022-08-06 12:57                         ` Lynn Winebarger
2022-08-06 15:39                           ` Lynn Winebarger
2022-08-06 20:23                             ` Working fully native-compiled "mega dump" (was Re: Loading tramp for dump goes into infinite regress) Lynn Winebarger
2022-08-06 20:52                               ` Lynn Winebarger
2022-07-25 20:11                     ` Loading tramp for dump goes into infinite regress Andrea Corallo
2022-07-31 20:22                       ` Lynn Winebarger
2022-08-03  9:58                         ` Lynn Winebarger
2022-08-03 12:22                           ` Eli Zaretskii
2022-08-03 14:53                             ` Native-compilation build process (was Re: Loading tramp for dump goes into infinite regress) Lynn Winebarger
2022-08-03 16:15                               ` Eli Zaretskii
2022-08-04  3:33                                 ` Lynn Winebarger
2022-08-05  1:57                                   ` Lynn Winebarger
2022-07-24 16:23               ` Loading tramp for dump goes into infinite regress Eli Zaretskii

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=87fsi5zj9n.fsf@yahoo.com \
    --to=luangruo@yahoo.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=owinebar@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 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).