bug#37006: 27.0.50; garbage collection not happening after 26de2d42

[Paul Eggert]

Eli Zaretskii wrote:

> We must
> have something in maybe_gc to notice the change and recompute the
> threshold.

I don't see why the threshold needs to be recomputed on each maybe_gc call. I 
suppose we could add a new builtin variable type, so that the threshold could be 
recomputed whenever GC-related builtin variables are changed; that should do the 
trick without slowing down maybe_gc. But is it that important to recalculate the 
GC threshold immediately? Variables like gc-cons-threshold aren't intended for 
fine-grained control over exactly when the GC is called; they're merely advice.

> We must also notice the memory-full condition there.

memory_full already does that, no? It sets consing_until_gc. Or are you thinking 
of some other memory-full condition?

>    if (!NILP (Vmemory_full))
>      consing_until_gc = memory_full_cons_threshold;
>    else
>      {
>        intptr_t threshold = min (max (GC_DEFAULT_THRESHOLD,
>                                      gc_cons_threshold >> 3),
>                                 OBJECT_CT_MAX);
>        if (FLOATP (Vgc_cons_percentage))
>         {
>           double tot = (XFLOAT_DATA (Vgc_cons_percentage)
>                         * total_bytes_of_live_objects ());
>           if (threshold < tot)
>             {
>               if (tot < OBJECT_CT_MAX)
>                 threshold = tot;
>               else
>                 threshold = OBJECT_CT_MAX;
>             }
>         }
>        consing_until_gc = threshold;
>      }
>
> First, gc_cons_threshold is an EMACS_INT, so putting its value into
> intptr_t is wrong in 32-bit builds --with-wide-int, right?

That's not a problem, since the above code does min (..., OBJECT_CT_MAX) on the 
result before storing it into intptr_t.

> using intptr_t for OBJECT_CT_MAX is wrong in such a build.

I don't see why it's wrong. The idea is to count the total number of object 
bytes in use. This cannot exceed the number of bytes addressable by pointers 
regardless of the width of EMACS_INT, so intptr_t is appropriate for such counts.
> And second, why does the code divide gc_cons_threshold by 8?  If the
> value of gc_cons_threshold is most-positive-fixnum, that is wrong, I
> think.  Did you mean to divide GC_DEFAULT_THRESHOLD instead?

Right you are; that's a typo. Thanks. I fixed that in master in the attached 
patch.

0001-Fix-GC-threshold-typo.patch
Description: Text Data