From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Pip Cet <pipcet@gmail.com>
Cc: 24548@debbugs.gnu.org
Subject: bug#24548: 25.2.50; Long GC delays with many non-detached markers (PATCH)
Date: Fri, 23 Mar 2018 10:22:18 -0400 [thread overview]
Message-ID: <jwv1sgaswkq.fsf-monnier+bug#24548@gnu.org> (raw)
In-Reply-To: <jwvd0zusxxh.fsf-monnier+bug#24548@gnu.org> (Stefan Monnier's message of "Fri, 23 Mar 2018 09:55:15 -0400")
> But if we call unchain_collected_markers from within the sweep phase
> (e.g. on every buffer we find), `gcmarkbit` should be
> sufficient/reliable. Or am I missing something?
At least the patch below seems to work as well.
Stefan
diff --git a/src/alloc.c b/src/alloc.c
index da01173fba..369592d70e 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -7095,7 +7091,9 @@ sweep_misc (void)
if (!mblk->markers[i].m.u_any.gcmarkbit)
{
if (mblk->markers[i].m.u_any.type == Lisp_Misc_Marker)
- unchain_marker (&mblk->markers[i].m.u_marker);
+ /* Make sure markers have been unchained from their buffer
+ in sweep_buffer before we collect them. */
+ eassert (!mblk->markers[i].m.u_marker.buffer);
else if (mblk->markers[i].m.u_any.type == Lisp_Misc_Finalizer)
unchain_finalizer (&mblk->markers[i].m.u_finalizer);
#ifdef HAVE_MODULES
@@ -7142,6 +7140,23 @@ sweep_misc (void)
total_free_markers = num_free;
}
+/* Remove BUFFER's markers that are due to be swept. This is needed since
+ we treat BUF_MARKERS and markers's `next' field as weak pointers. */
+static void
+unchain_dead_markers (struct buffer *buffer)
+{
+ struct Lisp_Marker *this, **prev = &BUF_MARKERS (buffer);
+
+ while ((this = *prev))
+ if (this->gcmarkbit)
+ prev = &this->next;
+ else
+ {
+ this->buffer = NULL;
+ *prev = this->next;
+ }
+}
+
NO_INLINE /* For better stack traces */
static void
sweep_buffers (void)
@@ -7160,6 +7175,7 @@ sweep_buffers (void)
VECTOR_UNMARK (buffer);
/* Do not use buffer_(set|get)_intervals here. */
buffer->text->intervals = balance_intervals (buffer->text->intervals);
+ unchain_dead_markers (buffer);
total_buffers++;
bprev = &buffer->next;
}
@@ -7179,8 +7195,8 @@ gc_sweep (void)
sweep_floats ();
sweep_intervals ();
sweep_symbols ();
- sweep_misc ();
sweep_buffers ();
+ sweep_misc ();
sweep_vectors ();
check_string_bytes (!noninteractive);
}
next prev parent reply other threads:[~2018-03-23 14:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-26 15:12 bug#24548: 25.2.50; Long GC delays with many non-detached markers (PATCH) Pip Cet
2018-03-23 13:55 ` Stefan Monnier
2018-03-23 14:22 ` Stefan Monnier [this message]
2018-03-23 15:10 ` Pip Cet
2018-03-23 15:11 ` Stefan Monnier
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='jwv1sgaswkq.fsf-monnier+bug#24548@gnu.org' \
--to=monnier@iro.umontreal.ca \
--cc=24548@debbugs.gnu.org \
--cc=pipcet@gmail.com \
/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.