unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Daniel Colascione <dancol@dancol.org>
To: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>
Cc: pipcet@gmail.com, emacs-devel@gnu.org
Subject: Re: Failing to GC killed buffers considered harmful
Date: Sun, 29 Mar 2020 12:06:56 -0700	[thread overview]
Message-ID: <5089e383-7b34-d9d6-a002-26312c5f3066@dancol.org> (raw)
In-Reply-To: <83r1xb3sbg.fsf@gnu.org>

On 3/29/20 11:54 AM, Eli Zaretskii wrote:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Sun, 29 Mar 2020 12:45:48 -0400
>> Cc: Daniel Colascione <dancol@dancol.org>, Pip Cet <pipcet@gmail.com>,
>>   emacs-devel@gnu.org
>>
>> Could we try and write out buffers such that they are read back as
>> something else (e.g. a special record with type `dead-dumped-buffer`)?
> 
> What problem will that solve?
> 
> The other buffers that we inherit from temacs are all frequently-used
> ones, so it makes sense to keep them.  A killed buffer isn't useful,
> by contrast.
> 
> We could perhaps avoid dumping buffers altogether, and instead create
> them all at startup, but it will probably also cause complications,
> e.g., because the frame we dump must have a window, which must have a
> buffer.  I hope that avoiding to dump that one buffer, even if that
> requires to add support for this in pdumper.c, will be easier.
> 

None of these measures is necessary. There's nothing special about a 
killed buffer: such a thing is just a lisp buffer object in a specific 
state. We just need to make sure that dumping buffer objects in this 
state works. The right approach isn't to prohibit dumping buffers 
generally for some reason.

And yes, you do have to dump killed buffers. If we have a Lisp reference 
to a buffer and we can't dump buffers, what do we do? Fail the dump? 
Replace the reference with the integer 5?

Yes, if we just remove the assertion, we'll end up with a dead buffer 
that's constantly marked because it lives in the pdumper image. So what? 
All pdumper objects are immortal. (But objects on clean pages do get 
evicted from memory eventually.)

Connecting buffer death to GC at all is just wrong. When we kill a 
buffer, we nuke the buffer's character array and interval tree and put 
the Lisp buffer object in a dead state. Then that object remains live 
(from Lisp POV) until its last reference disappears, at which point we 
reclaim the Lisp object. A buffer should be no different from any other 
pseudovector in this respect.



  reply	other threads:[~2020-03-29 19:06 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-29 14:23 Failing to GC killed buffers considered harmful Eli Zaretskii
2020-03-29 16:45 ` Stefan Monnier
2020-03-29 18:54   ` Eli Zaretskii
2020-03-29 19:06     ` Daniel Colascione [this message]
2020-03-29 19:24       ` Eli Zaretskii
2020-03-29 16:46 ` Pip Cet
2020-03-29 18:48   ` Eli Zaretskii
2020-03-29 19:07     ` Pip Cet
2020-03-29 19:12       ` Daniel Colascione
2020-03-29 19:25         ` Pip Cet
2020-03-29 19:28           ` Eli Zaretskii
2020-03-30 15:36             ` Pip Cet
2020-03-30 15:53               ` dancol
2020-03-30 17:07             ` Stefan Monnier
2020-03-30 17:02   ` Stefan Monnier
2020-03-30 18:32     ` Stefan Monnier
2020-03-30 18:51       ` Eli Zaretskii
2020-03-30 19:14         ` Daniel Colascione
2020-03-30 19:40         ` Stefan Monnier
2020-03-31 14:07           ` Eli Zaretskii
2020-03-31 14:09       ` Eli Zaretskii
2020-03-31 21:57         ` Stefan Monnier
2020-03-31 14:58       ` Pip Cet
2020-03-31 16:52         ` Stefan Monnier
2020-03-31 18:23           ` Pip Cet
2020-03-31 19:20             ` Stefan Monnier

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=5089e383-7b34-d9d6-a002-26312c5f3066@dancol.org \
    --to=dancol@dancol.org \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --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).