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

From: Helmut Eller <[email-masked]>
Date: Fri, 01 Aug 2025 13:44:08 +0200

On Fri, Aug 01 2025, Eli Zaretskii wrote:

[...]
>> 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.
>
> What is a "GC-managed object", for this purpose?  How can one
> determine whether a given object is or isn't GC-managed?

Objects that allocated on the GC heap and automatically freed are
GC-managed.

[...]
>> 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.
>
> Did you try to run interactively with gc-cons-percentage = 1.0?  If
> you did, can you share the experience?

No.  I usually run igc with an MPS debug build; it has much longer and
noticeable GC pauses than a regular built.

However, I have a bunch of benchmarks and those are executed inside GNU
screen [*].  I don't claim that the benchmarks are good or relevant or
anything.  For the longest time I didn't even know that batch mode uses
a different gc-cons-percentage.  Doh!  The results, with all its
badness, are:

The master-X versions are for gc-cons-percentage = X.  wgc is a branch
with a half finished Whipped GC.

>> For latency, we have no benchmarks; so I'm not convinced that igc
>> actually has lower latency.
>
> My anecdotal evidence from running the igc branch is unambiguous: it
> is significantly less "stuttering" than the master branch.

Is that with gc-cons-percentage = 0.1?

>> 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.
>
> So maybe some tuning is in order?

Definitely.

Helmut

[*] https://github.com/ellerh/igc-benchmarks