Re: last_marked array is now ifdef'ed away

["Mattias Engdegård" <mattias.engdegard@gmail.com>]

15 sep. 2024 kl. 16.21 skrev Eli Zaretskii <eliz@gnu.org>:

> There's no need for any evidence to keep the code which we always had.

Well, we didn't have it in Emacs 29, so one might be excused for thinking it wasn't a strict necessity.

> That won't help because GC crashes are seldom if ever reproducible.
> So if the trace is off, the information is gone and cannot be
> recovered in practice.

My experience is rather that in such cases the crash was already gone because there was no core dump or debugger attached anyway, but we then take the necessary steps to catch the bug next time – turn on core dumps (if possible), run with a debugger, enable checking, etc – and we always end up trapping the gremlin eventually.

Anyway, I'm going to re-enable the mark trace buffer for the sake of development peace; since it's important to you, that's also worth something. I shall add a configuration option for disabling it, with its trade-off clearly documented, so that users can make an informed decision, but the buffer will be enabled by default.


16 sep. 2024 kl. 20.07 skrev Andrea Corallo <acorallo@gnu.org>:

> 5% slowdown during GC is at worst 2.5% slowdown overall for GC intensive
> workloads.

It may not sound much but to a performance engineer this is actually quite a catch. This is because it's additive and independent of other improvements, and Emacs GC being what it is, it's also a matter of latency. If we only bothered with performance changes that give 50 % speed-up or more then we would never get anywhere at all.