unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Daniel Colascione" <dancol@dancol.org>
To: "Pip Cet" <pipcet@gmail.com>
Cc: Michael Heerdegen <michael_heerdegen@web.de>,
	Lars Ingebrigtsen <larsi@gnus.org>,
	36447@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
	Noam Postavsky <npostavs@gmail.com>
Subject: bug#36447: 27.0.50; New "Unknown keyword" errors
Date: Tue, 9 Jul 2019 20:01:14 -0700	[thread overview]
Message-ID: <7c22ff8d30102b8e4c2d2a766c0cf60b.squirrel@dancol.org> (raw)
In-Reply-To: <CAOqdjBdb5440pOMXU7aHqZ=U0Trr-ydx4uaTLV_py+_5WzeXLg@mail.gmail.com>

> On Mon, Jul 8, 2019 at 10:25 PM Noam Postavsky <npostavs@gmail.com> wrote:
>> I've switched byte-compile-cond-use-jump-table to nil for now, so you
>> shouldn't be hitting this anymore.
>
> Thanks.
>
>> > I know nothing about this, but did anybody want to fix this in a
>> > different way, or did the discussion just peter our?
>>
>> There were some suggestions about checking PURE_P or similar to see if
>> the copy is really needed, but then apparently PURE_P doesn't work at
>> all?  I've been meaning to check that out, because it seems like there
>> are still a few things which aren't making sense.
>
> It does seem like we've effectively given up pure space when we
> switched to pdumper. We still fill it and spend a lot of time making
> sure not to waste any, but it's then simply copied to the dump along
> with the rest of the dumped image.

We're at least combining identical objects, which is what this bug is about.

> It's still kept around in the final
> executable, so we're wasting quite a bit of disk space on it...

At least the executable pure space isn't paged in. I prefer not to waste
disk space, but wasting disk space without wasting memory is lower on my
list of priorities than other things.

> Most importantly, I think, the CHECK_IMPURE macro now does nothing
> (except waste a few cycles), and we can freely setcar what should be
> purecopied conses.
>
> (One thing we might do is introduce immutable conses, and use them for
> `read', pure space, and in a few other places).

We could use pureness information to relocate all the pure objects in the
dump so that we're less likely to take COW faults on them during runtime.
Right now, if a pure object and a regular object share a page in the dump
and we modify the regular object, we copy the pure object uselessly. Note
that we're not modifying these objects for GC, since we keep dump markbits
separate from the dump image (as we really should be doing for the heap in
general one day).






  reply	other threads:[~2019-07-10  3:01 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-30 18:23 bug#36447: 27.0.50; New "Unknown keyword" errors Michael Heerdegen
2019-06-30 18:43 ` Eli Zaretskii
2019-06-30 21:44   ` Michael Heerdegen
2019-07-01 12:25     ` Noam Postavsky
2019-07-01 13:20       ` Pip Cet
2019-07-01 22:04       ` Michael Heerdegen
2019-07-02  1:59         ` Stefan Kangas
2019-07-02 14:17           ` Eli Zaretskii
2019-07-02 13:29         ` Pip Cet
2019-07-02 15:35           ` Michael Heerdegen
2019-07-02 16:20             ` Noam Postavsky
2019-07-02 22:50               ` Pip Cet
2019-07-03 11:57                 ` Pip Cet
2019-07-05  1:59                   ` Michael Heerdegen
2019-07-05  6:35                     ` Pip Cet
2019-07-05  7:50                       ` Eli Zaretskii
2019-07-05  8:12                         ` Pip Cet
2019-07-05  8:25                           ` Eli Zaretskii
2019-07-05  8:36                             ` Pip Cet
2019-07-05  8:41                               ` Eli Zaretskii
2019-07-05  9:09                                 ` Pip Cet
2019-07-05 12:23                                   ` Robert Pluim
2019-07-05 12:33                                   ` Eli Zaretskii
2019-07-05 13:41                                     ` Pip Cet
2019-07-05 18:00                                     ` Stefan Monnier
2019-07-05 18:07                                       ` Eli Zaretskii
2019-07-05 20:16                                         ` Stefan Monnier
2019-07-05 18:57                                       ` Pip Cet
2019-07-05 19:13                                         ` Eli Zaretskii
2019-07-05 20:21                                         ` Stefan Monnier
2019-07-05 21:52                                           ` Pip Cet
2019-07-05 22:10                                             ` Stefan Monnier
2019-07-06  6:45                                               ` Eli Zaretskii
2019-07-06 15:08                                                 ` Pip Cet
2019-07-09 21:05                                                   ` Stefan Monnier
2019-07-10  2:38                                                     ` Eli Zaretskii
2019-07-10  3:19                                                       ` Daniel Colascione
2019-07-10 15:01                                                         ` Pip Cet
2019-07-10 17:16                                                           ` Daniel Colascione
2019-07-10 20:14                                                             ` Pip Cet
2019-07-06 15:32                                             ` Michael Heerdegen
2019-07-08 17:30                                               ` Lars Ingebrigtsen
2019-07-08 17:58                                                 ` Pip Cet
2019-07-08 22:18                                                   ` Lars Ingebrigtsen
2019-07-08 22:25                                                     ` Noam Postavsky
2019-07-09 14:00                                                       ` Pip Cet
2019-07-10  3:01                                                         ` Daniel Colascione [this message]
2019-07-14 14:06                                                           ` Noam Postavsky
2019-07-08 23:22                                                     ` Stefan Monnier
2019-07-08 22:23                                                   ` Michael Heerdegen
2019-07-09 15:43                                                     ` Eli Zaretskii
2019-07-09 20:15                                                   ` Stefan Monnier
2019-07-05  7:55                       ` Katsumi Yamaoka

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=7c22ff8d30102b8e4c2d2a766c0cf60b.squirrel@dancol.org \
    --to=dancol@dancol.org \
    --cc=36447@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=michael_heerdegen@web.de \
    --cc=monnier@iro.umontreal.ca \
    --cc=npostavs@gmail.com \
    --cc=pipcet@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).