GNU bug report logs - #76538
31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs.

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: Ihor Radchenko <yantar92 <at> posteo.net>, Helmut Eller <eller.helmut <at> gmail.com>, Gerd Möllmann <gerd.moellmann <at> gmail.com>, joaomoreira <at> gmx.se, 76538 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs.
Date: Mon, 03 Mar 2025 09:23:47 -0500

> Even though we now emulate the alloc.c code quite precisely, I think
> feature/igc will accumulate many more markers than alloc.c, since weak
> objects are collected quite rarely by MPS, IME.

One of the benefits of using a better markers cache would be to reduce
reliance on the GC, indeed.  E.g. my array-with-gap will tend not to
accumulate cache-markers indefinitely because it always finds the
closest (cache-)marker before deciding whether we need to add
another one.

[ Of course, if the GC never triggers, cache-markers can still
  accumulate needlessly, e.g. if you regularly `erase-buffer`, which
  causes all the (cache-)markers to be moved to point-min, or in
  a comint buffer where you regularly cut the beginning to keep the
  buffer from growing indefinitely.  ]

> Maybe we need to mark "automatic" markers which are never exposed to
> Lisp and splat them in DO_MARKERS if there are too many of them?

Getting rid of the GC's involvement in flushing the cache would be good.
Doing it at every DO_MARKERS might be requires care if we don't want it
to be too costly.
[ Also, with the current un-ordered setup, it could be hard to know
  which ones to throw out.  Again, a better cache would help in this
  regard.  ]


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.