From: Eli Zaretskii <eliz@gnu.org>
To: "Mattias Engdegård" <mattiase@acm.org>
Cc: jrm@ftfl.ca, eggert@cs.ucla.edu, 37006@debbugs.gnu.org
Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42
Date: Tue, 13 Aug 2019 20:04:13 +0300 [thread overview]
Message-ID: <83ftm5ro8i.fsf@gnu.org> (raw)
In-Reply-To: <3E8F9821-8C8B-48AD-BC88-7191450C4D7E@acm.org> (message from Mattias Engdegård on Tue, 13 Aug 2019 18:48:05 +0200)
> 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?
next prev parent reply other threads:[~2019-08-13 17:04 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 [this message]
2019-08-13 17:29 ` Mattias Engdegård
2019-08-13 17:21 ` Paul Eggert
2019-08-13 17:53 ` Eli Zaretskii
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=83ftm5ro8i.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.