From: Paul Eggert <eggert@cs.ucla.edu>
To: Eli Zaretskii <eliz@gnu.org>, Joseph Mingrone <jrm@ftfl.ca>
Cc: mattiase@acm.org, 37006@debbugs.gnu.org
Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42
Date: Tue, 13 Aug 2019 10:21:51 -0700 [thread overview]
Message-ID: <2687613f-ba89-25cf-9517-5311106aef9a@cs.ucla.edu> (raw)
In-Reply-To: <83wofis508.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 2184 bytes --]
Eli Zaretskii wrote:
> 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. But is it that important to recalculate the
GC threshold immediately? Variables like gc-cons-threshold aren't intended for
fine-grained control over exactly when the GC is called; they're merely advice.
> We must also notice the memory-full condition there.
memory_full already does that, no? It sets consing_until_gc. Or are you thinking
of some other memory-full condition?
> if (!NILP (Vmemory_full))
> consing_until_gc = memory_full_cons_threshold;
> else
> {
> intptr_t threshold = min (max (GC_DEFAULT_THRESHOLD,
> gc_cons_threshold >> 3),
> OBJECT_CT_MAX);
> if (FLOATP (Vgc_cons_percentage))
> {
> double tot = (XFLOAT_DATA (Vgc_cons_percentage)
> * total_bytes_of_live_objects ());
> if (threshold < tot)
> {
> if (tot < OBJECT_CT_MAX)
> threshold = tot;
> else
> threshold = OBJECT_CT_MAX;
> }
> }
> consing_until_gc = threshold;
> }
>
> 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.
> using intptr_t for OBJECT_CT_MAX is wrong in such a build.
I don't see why it's wrong. The idea is to count the total number of object
bytes in use. This cannot exceed the number of bytes addressable by pointers
regardless of the width of EMACS_INT, so intptr_t is appropriate for such counts.
> And second, why does the code divide gc_cons_threshold by 8? If the
> value of gc_cons_threshold is most-positive-fixnum, that is wrong, I
> think. Did you mean to divide GC_DEFAULT_THRESHOLD instead?
Right you are; that's a typo. Thanks. I fixed that in master in the attached patch.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-GC-threshold-typo.patch --]
[-- Type: text/x-patch; name="0001-Fix-GC-threshold-typo.patch", Size: 1138 bytes --]
From 1e5bda273a67f960fb834007f4653a630cd67ce9 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 13 Aug 2019 10:03:41 -0700
Subject: [PATCH] Fix GC threshold typo
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Problem reported by Eli Zaretskii (Bug#37006#25).
* src/alloc.c (garbage_collect_1): Fix typo in threshold calc.
Go back to dividing by 10 since the numerator’s a constant now.
Problem introduced in 2019-07-21T02:40:03Z!eggert@cs.ucla.edu.
---
src/alloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/alloc.c b/src/alloc.c
index 39833f8dec..c7419e2fa5 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -5932,8 +5932,8 @@ garbage_collect_1 (struct gcstat *gcst)
consing_until_gc = memory_full_cons_threshold;
else
{
- intptr_t threshold = min (max (GC_DEFAULT_THRESHOLD,
- gc_cons_threshold >> 3),
+ intptr_t threshold = min (max (GC_DEFAULT_THRESHOLD / 10,
+ gc_cons_threshold),
OBJECT_CT_MAX);
if (FLOATP (Vgc_cons_percentage))
{
--
2.17.1
next prev parent reply other threads:[~2019-08-13 17:21 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 [this message]
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=2687613f-ba89-25cf-9517-5311106aef9a@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=37006@debbugs.gnu.org \
--cc=eliz@gnu.org \
--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.