GNU bug report logs - #74547
31.0.50; igc: assertion failed in buffer.c

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Geza Herman <geza.herman <at> gmail.com>
Cc: Pip Cet <pipcet <at> protonmail.com>, Óscar Fuentes <oscarfv <at> telefonica.net>, 74547 <at> debbugs.gnu.org
Subject: bug#74547: 31.0.50; igc: assertion failed in buffer.c
Date: Sun, 01 Dec 2024 20:41:33 +0100

Geza Herman <geza.herman <at> gmail.com> writes:

> On 12/1/24 16:48, Pip Cet wrote:
>
>  Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>  Yeah, I'd prefer using Lisp_Vectors too, and it was actually implemented
> at some point, but removed again, see
>
>   https://yhetil.org/emacs-devel/87edc1rzig.fsf <at> gmail.com/
>
> I vaguely remember a longer thread about GC in json.c at the time. Could
> be that that was before igc became a realistic possibility, don't
> remember.
>
>
> Okay, sounds like it's a political issue. I'll push the first patch
> which keeps changes to a minimum.
>
> Pip
>
> Back then, the future of the new GC was a question, so Gerd said
> (https://lists.gnu.org/archive/html/emacs-devel/2024-03/msg00544.html) that
> "Please don't take my GC efforts into consideration. That may succeed or not. But this is also a matter of good design,
> using the stack, (which BTW pdumper does, too), vs. bad design." That's why we went with the fastest implementation that
> doesn't use lisp vectors for storage. But we suspected that this JSON parser design will likely cause a problem with the
> new GC. So I think even if it turned out that the current problem was not caused by the parser, I still think that there
> should be something done about this JSON parser design to eliminate this potential problem. The lisp vector based
> approach was reverted because it added an extra pressure to the GC. For large JSON messages, it doesn't matter too much,
> but when the JSON is small, the extra GC time made the parser measurably slower. But, as far as I remember, that version
> hadn't have the small internal storage optimization yet. If we convert back to the vector based approach, the extra GC
> pressure will be smaller (compared to the original vector based approach without the internal storage), as for smaller
> sizes the vector won't be actually used.
>
> Géza

Sorry again for not remembering this earlier. It only resurfaced slowly
in my mind when I saw Pip's patch.

Previous Next

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