Re: Garbage collector: is 800kb a good default?

[Dmitrii Korobeinikov]

> It's called "incremental GC".  XEmacs does it this way.

That's cool, didn't know that!

> to have, indeed.  It's often not too hard to go from "incremental" to
> "concurrent", tho, so I think if we want to go there we should aim for
> a concurrent GC.

I see.

> I'm personally not too worried about that (I don't run much more than
> Emacs on my machines), but a high GC threshold tends to lead to a large
> heap indeed and the problem with it (for me) is that it tends to make
> the GC yet slower (to which the naive reaction would be to increase the
> threshold yet further to make GC even less frequent) and it can also
> slow down the non-GC execution by increasing pressure on the memory
> hierarchy (using more VM pages and more cache lines, reducing
> effectiveness of the CPU's prefetcher) because the heap is more
> sparsely populated.
>
> This is not documented with precise measurements, sadly.
> So it's far from clear how much is too much.

Thanks for expanding on these, I didn't know the details.

For a start, I guess, just timing garbage-collect would work? Then
what's left is to pick a few various ways to generate the garbage.

Best,
DK

пт, 10 апр. 2020 г. в 01:05, Stefan Monnier <address@hidden>:
>
> > Maybe it would be possible to garbage collect in chunks and check
> > after each chunk for input?
>
> It's called "incremental GC".  XEmacs does it this way.  It'd be nice
> to have, indeed.  It's often not too hard to go from "incremental" to
> "concurrent", tho, so I think if we want to go there we should aim for
> a concurrent GC.
>
>
>         Stefan
>