bug#74547: 31.0.50; igc: assertion failed in buffer.c

[Geza Herman]

On 12/1/24 16:48, Pip Cet wrote:

> Gerd Möllmann <gerd.moellmann@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@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