From: Pip Cet <pipcet@gmail.com>
To: emacs-devel@gnu.org, Paul Eggert <eggert@cs.ucla.edu>
Subject: Re: [Emacs-diffs] master 5d4dd55: Fix lifetime error in previous patch
Date: Mon, 22 Jul 2019 04:12:05 +0000 [thread overview]
Message-ID: <CAOqdjBce2JDfVgfiZMUtEPU3h=9+fEdZaCWVYuetPPfoCNp4iw@mail.gmail.com> (raw)
In-Reply-To: <20190721193222.8C19E20BE2@vcs0.savannah.gnu.org>
[-- Attachment #1: Type: text/plain, Size: 541 bytes --]
On Sun, Jul 21, 2019 at 7:32 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> static void
> -allow_garbage_collection (void *ptr)
> +allow_garbage_collection (intmax_t consing)
> {
> - object_ct *p = ptr;
> - consing_until_gc = *p;
> + consing_until_gc = consing;
Shouldn't we count the allocations that happened while GC was
inhibited and subtract them from consing_until_gc afterwards?
Also, should garbage_collect_1 use inhibit_garbage_collection rather
than fiddling with consing_until_gc directly?
Attaching a patch that does both.
[-- Attachment #2: 0001-Trigger-GC-earlier-after-garbage-collection-was-inhi.patch --]
[-- Type: text/x-patch, Size: 1199 bytes --]
From 7da1122b9bf4f0ab8da6958bca36c9bc0726564e Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@gmail.com>
Date: Mon, 22 Jul 2019 04:09:29 +0000
Subject: [PATCH] Trigger GC earlier after garbage collection was inhibited
* src/alloc.c (allow_garbage_collection): Don't ignore allocations
that happen while garbage collection is inhibited.
(garbage_collect_1): use `inhibit-garbage-collection'.
---
src/alloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/alloc.c b/src/alloc.c
index aa9200f2eb..a32302f6e2 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -5507,7 +5507,7 @@ staticpro (Lisp_Object const *varaddress)
static void
allow_garbage_collection (intmax_t consing)
{
- consing_until_gc = consing;
+ consing_until_gc += consing - OBJECT_CT_MAX;
garbage_collection_inhibited--;
}
@@ -5823,7 +5823,7 @@ garbage_collect_1 (struct gcstat *gcst)
/* In case user calls debug_print during GC,
don't let that cause a recursive GC. */
- consing_until_gc = OBJECT_CT_MAX;
+ inhibit_garbage_collection ();
/* Save what's currently displayed in the echo area. Don't do that
if we are GC'ing because we've run out of memory, since
--
2.22.0
next parent reply other threads:[~2019-07-22 4:12 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190721193221.1964.53182@vcs0.savannah.gnu.org>
[not found] ` <20190721193222.8C19E20BE2@vcs0.savannah.gnu.org>
2019-07-22 4:12 ` Pip Cet [this message]
2019-07-22 13:40 ` [Emacs-diffs] master 5d4dd55: Fix lifetime error in previous patch Stefan Monnier
2019-07-23 1:06 ` Paul Eggert
2019-07-22 15:00 ` Changes in GC and in pure space (was: [Emacs-diffs] master 5d4dd55: Fix lifetime error in previous patch) Eli Zaretskii
2019-07-22 17:47 ` Paul Eggert
2019-07-22 18:19 ` Changes in GC and in pure space Eli Zaretskii
2019-07-22 19:58 ` Stefan Monnier
2019-07-23 1:43 ` Paul Eggert
2019-07-23 14:46 ` Eli Zaretskii
2019-07-23 16:27 ` Paul Eggert
2019-07-23 16:58 ` Eli Zaretskii
2019-07-23 2:25 ` Eli Zaretskii
2019-07-22 19:05 ` Changes in GC and in pure space (was: [Emacs-diffs] master 5d4dd55: Fix lifetime error in previous patch) Pip Cet
2019-07-23 14:56 ` Eli Zaretskii
2019-07-23 15:33 ` Changes in GC and in pure space Stefan Monnier
2019-07-24 3:06 ` Richard Stallman
2019-08-15 9:34 ` Changes in GC and in pure space (was: [Emacs-diffs] master 5d4dd55: Fix lifetime error in previous patch) Paul Eggert
2019-08-16 13:34 ` Pip Cet
2019-08-22 0:25 ` Paul Eggert
2019-08-22 2:06 ` Paul Eggert
2019-08-22 5:36 ` Paul Eggert
2019-09-04 6:05 ` Paul Eggert
2019-09-04 14:51 ` Eli Zaretskii
2019-09-04 16:56 ` Paul Eggert
2019-09-04 17:36 ` Daniel Colascione
2019-09-04 17:45 ` Changes in GC and in pure space Stefan Monnier
2019-09-04 18:34 ` Óscar Fuentes
2019-09-04 19:15 ` Paul Eggert
2019-09-05 7:04 ` Paul Eggert
2019-07-24 2:58 ` Changes in GC and in pure space (was: [Emacs-diffs] master 5d4dd55: Fix lifetime error in previous patch) Richard Stallman
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAOqdjBce2JDfVgfiZMUtEPU3h=9+fEdZaCWVYuetPPfoCNp4iw@mail.gmail.com' \
--to=pipcet@gmail.com \
--cc=eggert@cs.ucla.edu \
--cc=emacs-devel@gnu.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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).