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

[Mattias Engdegård]

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.