Subject: bug#79116: 31.0.50; Crash on IGC build

From: Helmut Eller <[email-masked]>
Date: Fri, 01 Aug 2025 09:28:07 +0200

On Fri, Aug 01 2025, Eli Zaretskii wrote:

>> From: Helmut Eller <[email-masked]>
>> Cc: Eli Zaretskii <[email-masked]>,  [email-masked],
>>   [email-masked],  [email-masked]
>> Date: Thu, 31 Jul 2025 18:46:49 +0200
>> 
>> Anyway, my concern is a bit more general: I think that objects without
>> memory barriers, (e.g. structs allocated with malloc) should be scanned
>> as roots.
>
> This is very general, and in that general form quite scary.  Emacs
> allocates with malloc all over the place, and most such allocations
> have nothing to do with Lisp objects.

If there aren't any Lisp objects involved, then there is no problem.
The problematic cases are (or could be) structs that are malloc'd and
contain references to GC-managed objects.

> So I hope we can have rules
> that determine whether a given malloc'ed object needs to be scanned or
> not, because otherwise we'll force MPS to scan too much, and lose the
> single most important advantage it gives us: that its GC cycles are
> fast and don't stop the application code for prolonged periods of
> time.

Yes, it would require more work during the root scanning phase.

However, performance of igc is already unconvincing: throughput with the
old GC and gc-cons-percentage = 1.0 is better than with igc.  For
latency, we have no benchmarks; so I'm not convinced that igc actually
has lower latency.

Even if igc has lower latency, the current way igc triggers
opportunistic GC doesn't work well: I've often seen "Opportunism: client
predicts plenty of idle time, so start full collection." messages when I
was about to type something.

Helmut