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

[Eli Zaretskii <eliz@gnu.org>]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Tue, 13 Aug 2019 18:48:05 +0200
> Cc: jrm@ftfl.ca, eggert@cs.ucla.edu, 37006@debbugs.gnu.org
> 
> > Yes, but the full calculation of the threshold is more complicated
> > than that.  For starters, how do you handle gc_cons_threshold values
> > that are smaller than GC_DEFAULT_THRESHOLD / 10 under your proposal?
> > There are use cases where the value was below that before and is above
> > now, or the other way around, or was below and stays below.
> 
> If a change to gc_cons_threshold has us end up in garbage_collect too soon, we can just adjust the bias and consing_until_gc and continue; the cost for doing so is small and amortised. Conversely, if the user raises gc_cons_threshold beyond the limit (OBJECT_CT_MAX), the intention is clearly to inhibit GC anyway.
> 
> > And that's even before we consider other complications: when
> > memory-full is non-nil, we should use a different threshold; and what
> > about user changes to gc-cons-percentage?
> 
> The check for memory-full was already eliminated from maybe_gc by changing consing_until_gc when that condition occurs, which seems reasonable enough. Regarding changes gc-cons-percentage, the effect will just be delayed to next GC --- is this really harmful?

IOW, you think that whatever this changes in user-facing behavior is
unimportant, and we shouldn't be bothered about it.  I happen to
disagree.

> I could be wrong about all this; I'm a bit confused by the threshold computation, too. However, Paul's consolidation of conditions in the hot and inlined maybe_gc makes eminently sense to me.

I cannot say the same thing myself, sorry.  Making a frequent
operation faster definitely makes sense, even if the speedup is minor.
But doing that and as result breaking use cases that worked for years,
or even just changing their effects in a tangible manner? what's our
excuse for that?