emacs-devel
[Top][All Lists]
Advanced

[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:12:09 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 3/29/20 12:07 PM, Pip Cet wrote:
On Sun, Mar 29, 2020 at 6:48 PM Eli Zaretskii <address@hidden> wrote:
From: Pip Cet <address@hidden>
Date: Sun, 29 Mar 2020 16:46:03 +0000
Cc: Daniel Colascione <address@hidden>, address@hidden

We could, of course, remove the assertion, but then we are left with a
dead buffer that will never be GC'ed, AFAIU, because objects that come
from the portable dump are considered constantly marked.

The same is true of all other objects, though, right?

You mean, that they are considered marked?  Yes.

Well, if my initial experiments are correct, we correctly remove the
killed buffer from the all_buffers list; we simply fail to free the
memory it occupied. That seems like an acceptable loss to me.

It seems like it's simply a bad assert to me.

Which one?

The one in buffer.c:

       /* Only buffers with allocated buffer text should be present at
      this point in temacs.  */
       FOR_EACH_BUFFER (b)
         {
       eassert (b->text->beg != NULL);
     }

The problem appears to be that "all_buffers" points to a killed
buffer, and is remembered by pdumper.

Yes, because pdumper dumps all the Lisp objects present at that point,
after performing GC.  What else can it do?

My understanding is that pdumper only dumps Lisp objects reachable
from the heap (not the stack). Buffers are an exception only because
of all_buffers, which we could rebuild from the dumped buffers.

The call to garbage_collect in Fdump_emacs_portable doesn't actually
reduce image size.

It runs finalizers, which can free additional memory.



reply via email to

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