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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: mattiase@acm.org, 37006@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 13 Aug 2019 10:21:51 -0700
> 
> > We must
> > have something in maybe_gc to notice the change and recompute the
> > threshold.
> 
> 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.

I don't think I understand what this proposal means in practice.  Can
you elaborate, or show an example?

> But is it that important to recalculate the GC threshold
> immediately?

How else would you succeed in reacting to the change "soon enough"?
In the use case which triggered this bug report, setting
gc-cons-threshold to a very large number disables GC for an extremely
long time, and all that time the gc-cons-threshold changes made by the
user are not acted upon.

IOW, we could perhaps explain away a delay of seconds in acting upon
the change, but we surely cannot explain away a delay of hours, let
alone days.

> Variables like gc-cons-threshold aren't intended for fine-grained
> control over exactly when the GC is called; they're merely advice.

Yes, but abrupt changes, like to most-positive-fixnum and then back to
much smaller values, should produce at least approximately the
expected behavior.  In particular, changing from most-positive-fixnum
to a value like 800000 should cause a GC "soon enough".  If we don't
test the value inside maybe_gc, what alternative mechanisms would you
suggest to produce such an effect?

> > We must also notice the memory-full condition there.
> 
> memory_full already does that, no? It sets consing_until_gc.

It sets it to a positive value, so no immediate GC will follow.  The
original code was setting the threshold to a very small value, so GC
would happen immediately.  I think the code in memory_full which sets
consing_until_gc should be amended to (a) not raise consing_until_gc
if the current value is already below memory_full_cons_threshold, and
(b) probably even set it to the negative of sizeof (struct cons_block)
so as to cause an immediate GC.

> > 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.

??? But that effectively disallows/ignores values of gc-cons-threshold
above LONG_MAX.  Why would we make such a backward-incompatible change?
When the user sets the value of that variable, the variable should
keep its value, and we should be able to compare the threshold with
the value of the user variable.  If nothing else, arbitrarily throwing
away high-order bits of the value is a sure path towards bugs due to
confusion between these two value ranges.

> > using intptr_t for OBJECT_CT_MAX is wrong in such a build.
> 
> I don't see why it's wrong.

Because OBJECT_CT_MAX should have the value EMACS_INT_MAX.