Re: last_marked array is now ifdef'ed away

[Eli Zaretskii]

> From: Mattias Engdegård <mattias.engdegard@gmail.com>
> Date: Sat, 14 Sep 2024 19:05:31 +0200
> Cc: emacs-devel@gnu.org
> 
> 13 sep. 2024 kl. 17.21 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> > But if a user reports a crash inside GC, that's basically the only
> > trace we have to try and understand what caused the crash, especially
> > if the debug info was stripped.  That's why this code was always on by
> > default.
> 
> Yes, I understand that -- nevertheless it is a bit of a waste to spend time 
> on something that is only rarely used (apparently it took over 2 years before 
> anyone noticed, and I know you aren't one for keeping quiet about this sort 
> of thing).

That's the nature of things that are needed rarely.  But when they
_are_ needed, there's nothing to replace them, and that's when you
appreciate their existence.  Like safety belts, these features are
never a waste.

> And that is with LAST_MARKED_SIZE downgraded from the default 512 to just 16 
> which seemed more reasonable. (512 entries is 4 KiB of L1D cache which seems 
> extravagant, but I presume the size wasn't given much thought at the time.)

16 is way too few.  GC is deeply recursive, and when I used this, I
almost always had to look at much more than 16 objects.

> Perhaps it's not a big surprise after all: the GC marking loop has 
> data-dependent branches and data-dependent loads, and we are likely to be 
> bound by instructions in flight rather than execution resources; maybe any 
> added instructions and memory traffic will just make it worse.
> 
> > My main concern is not bitrot, it's actually being able to debug
> > crashes inside GC.
> 
> I'm quite sympathetic to that goal but it would be good if we could do it 
> more cheaply. You can inspect the mark_stack structure; I've found this to 
> help quite a bit.

That's not the same, and doesn't show all the objects.

I'm quite confident that I want this be turned on again.