Re: Failing to GC killed buffers considered harmful

[Daniel Colascione]

On 3/29/20 11:54 AM, Eli Zaretskii wrote:
> > From: Stefan Monnier <address@hidden>
> > Date: Sun, 29 Mar 2020 12:45:48 -0400
> > Cc: Daniel Colascione <address@hidden>, Pip Cet <address@hidden>,
> >   address@hidden
> >
> > 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.