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

["Mattias Engdegård" <mattiase@acm.org>]

13 aug. 2019 kl. 17.37 skrev Eli Zaretskii <eliz@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?

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.