[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Failing to GC killed buffers considered harmful

From: Daniel Colascione
Subject: Re: Failing to GC killed buffers considered harmful
Date: Sun, 29 Mar 2020 12:06:56 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

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>,

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 via email to

[Prev in Thread] Current Thread [Next in Thread]