[Top][All Lists]

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

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

From: Paul Eggert
Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42
Date: Tue, 13 Aug 2019 10:21:51 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

Eli Zaretskii wrote:

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

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;
       intptr_t threshold = min (max (GC_DEFAULT_THRESHOLD,
                                     gc_cons_threshold >> 3),
       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;
                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 

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

reply via email to

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