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: Pip Cet
Subject: Re: Failing to GC killed buffers considered harmful
Date: Tue, 31 Mar 2020 18:23:40 +0000

On Tue, Mar 31, 2020 at 4:52 PM Stefan Monnier <address@hidden> wrote:
> >> The patch below seems to work.
> > But it changes gcstat definitions (killed buffers are no longer
> > counted towards total_buffers).
>
> Indeed (instead all the `struct buffer` objects are now included in the
> count of (pseudo)vectors).
> I find this of no consequence and I don't
> think the GC algorithm should adapt to the gcstat (it should be the
> other way around).

Hmm. My argument is circular, and thus invalid: with all_buffers,
having many killed but uncollectable buffers is a problem, so we
should include accurate information about that in report-emacs-bug.
Without all_buffers, killed buffers only eat a bit of memory, so
there's no negative consequence to not counting them accurately.

> > buffer text.
> The buffer text is not stored within the `struct buffer` object, so no.

struct buffer_text, I meant. If we ever think about collecting the
actual text of a buffer because it's being garbage-collected, that
would be something different.

> > Next, it might be nice to have anonymous buffers that are
> > garbage-collected automatically and don't need to be killed. *ducks*
> Did I hear something or was it just the wind?

Well, I have created temporary buffers to act as, essentially, mutable
strings. I see no reason I have to kill
expensively-but-efficiently-implemented mutable strings explicitly
before having them collected! More seriously, I do think making
buffers more lightweight would be a good thing, perhaps even having an
immutable string without text properties/mutable string with gap and
some buffer properties/full-blown buffer spectrum.

(As I realize someone here usually demands use cases: I'd like to fix
the hash table printing code to print hashes predictably. That
requires sorting their keys by something predictable. Their printed
presentation is usually good enough, but that requires
prin1-to-string, which uses a buffer. It's currently too slow.)

> Indeed, my patch doesn't have anything to do with the original problem,

I don't see how the original problem would fail to be solved by your
patch. Pdumper doesn't dump all objects that survive GC, only those it
can reach from the heap (plus some collateral damage). So your patch
restores that requirement precisely, and we can keep the assert()
unless we decide we want to relax our standards and allow killed
buffers during the dump.



reply via email to

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