emacs-devel
[Top][All Lists]
Advanced

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

Re: last_marked array is now ifdef'ed away


From: Mattias Engdegård
Subject: Re: last_marked array is now ifdef'ed away
Date: Tue, 17 Sep 2024 12:15:16 +0200

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.




reply via email to

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