GNU bug report logs - #37006
27.0.50; garbage collection not happening after 26de2d42

Previous Next

Full log

Message #25 received at 37006 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Joseph Mingrone <jrm <at> ftfl.ca>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: mattiase <at> acm.org, 37006 <at> debbugs.gnu.org
Subject: Re: bug#37006: 27.0.50; garbage collection not happening after
 26de2d42
Date: Mon, 12 Aug 2019 19:49:43 +0300

> From: Joseph Mingrone <jrm <at> ftfl.ca>
> Cc: mattiase <at> acm.org,  eggert <at> cs.ucla.edu,  37006 <at> debbugs.gnu.org
> Date: Mon, 12 Aug 2019 11:34:18 -0300
> 
> The fix did not initially work for me.  I tested a bit more.  With
> 
> 1. emacs -Q
> 2. (setq garbage-collection-messages t)
> 3. page through xdisp.c
> 
> I saw lots of garbage collection messages.  But, with my init.el there
> were no such messages.  My init.el looked like this.
> 
> ----------------------------------------------------
> (setq gc-cons-threshold most-positive-fixnum)
> 
> ;; contents of init.el here
> 
> (setq gc-cons-threshold 800000) ;; default value
> ----------------------------------------------------
> 
> When I removed the surrounding setqs, garbage collection message were
> shown again when paging through xdisp.c.
> 
> I assume that temporarily setting `gc-cons-threshold' to a large number
> to temporarily prevent garbage collection, then setting it back to a
> reasonable value should be acceptable.

Yes, of course.  There's a separate bug in the recent GC-related
changes.  Thanks for pointing this out.

Paul, the current method of updating consing_until_gc only in
garbage_collect_1 isn't workable, because it doesn't support the (very
popular nowadays) paradigm of temporarily setting gc-cons-threshold
very high: doing so avoids calling garbage_collect_1, and thus the
change of the threshold back to a lower value is never seen.  We must
have something in maybe_gc to notice the change and recompute the
threshold.  We must also notice the memory-full condition there.

We need to fix this ASAP, please.

I also don't think I understand the details of the threshold
calculations:

  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?  For the
same reason, using intptr_t for OBJECT_CT_MAX is wrong in such a
build.

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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.