From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: jrm@ftfl.ca, mattiase@acm.org, 37006@debbugs.gnu.org
Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42
Date: Tue, 13 Aug 2019 20:53:38 +0300 [thread overview]
Message-ID: <83ef1prly5.fsf@gnu.org> (raw)
In-Reply-To: <2687613f-ba89-25cf-9517-5311106aef9a@cs.ucla.edu> (message from Paul Eggert on Tue, 13 Aug 2019 10:21:51 -0700)
> 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.
next prev parent reply other threads:[~2019-08-13 17:53 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org>
2019-08-11 16:23 ` bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Mattias Engdegård
2019-08-11 17:07 ` Eli Zaretskii
[not found] ` <83h86nu0pq.fsf@gnu.org>
[not found] ` <86pnlbphus.fsf@phe.ftfl.ca>
2019-08-12 2:31 ` Eli Zaretskii
2019-08-12 14:34 ` Joseph Mingrone
2019-08-12 16:49 ` Eli Zaretskii
2019-08-12 17:00 ` Mattias Engdegård
2019-08-13 15:37 ` Eli Zaretskii
2019-08-13 16:48 ` Mattias Engdegård
2019-08-13 17:04 ` Eli Zaretskii
2019-08-13 17:29 ` Mattias Engdegård
2019-08-13 17:21 ` Paul Eggert
2019-08-13 17:53 ` Eli Zaretskii [this message]
2019-08-13 19:32 ` Paul Eggert
2019-08-14 16:06 ` Eli Zaretskii
2019-08-15 1:37 ` Paul Eggert
2019-08-15 14:17 ` Eli Zaretskii
2019-08-15 18:51 ` Paul Eggert
2019-08-15 19:34 ` Eli Zaretskii
2019-09-14 7:51 ` Paul Eggert
2019-09-14 8:30 ` Eli Zaretskii
2019-08-11 12:39 Joseph Mingrone
2019-08-11 15:13 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83ef1prly5.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=37006@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=jrm@ftfl.ca \
--cc=mattiase@acm.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.