emacs-devel
[Top][All Lists]
Advanced

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

Re: Opportunistic GC


From: Pip Cet
Subject: Re: Opportunistic GC
Date: Mon, 8 Mar 2021 15:39:07 +0000

On Mon, Mar 8, 2021 at 3:23 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Mon, 8 Mar 2021 15:02:18 +0000
> > Cc: rudalics@gmx.at, Stefan Monnier <monnier@iro.umontreal.ca>, 
> > emacs-devel@gnu.org
> >
> > For conses, it's easy. Instead of keeping the mark bits in the cons
> > block, we keep a pointer to the mark bits in the cons block, and
> > allocate the mark bits separately and (hopefully) on a different page.

> And for others?

Symbols: there's probably no need, as there are rarely sessions with
millions of symbols.
Floats: work just as conses do.
Strings: I don't think there are millions of short strings on the
heap, usually, but I'm not sure. Anyway, they're just like vectors.
Vectors: That's the difficult one; small vectors are kept in vector
blocks, and we'd need to have one bit per vector, which would mean one
bit for every two lisp words in the vector block, IIUC. So a storage
size increase of 1/128, 1/64 on 32-bit machines. Large vectors are,
well, large, so we can afford to keep an entire malloc() block for
their single mark bit, which would also come out to 1/128 using
typical numbers, if I got the math right.

But this would be mere optimization, of course.

> Also, doesn't it mean you increase the memory required for a cons by a
> factor of 1.5, as it now needs one more member (3 words instead of 2)?

There'd be one pointer per cons block, not one per cons, so the factor
is 1.008 on this machine.

Pip



reply via email to

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