Re: I created a faster JSON parser

[Mattias Engdegård]

12 mars 2024 kl. 11.20 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:

> Yes, I'm grumbling because record_..._mark assumes GC is mark-sweep. And
> it's really super ugly to work around.
> 
> And if you disable GC, I'll be grumbling because that's not good for a
> concurrent GC.

These are problems we clearly need to solve, but I don't think we should hold 
Géza's improved JSON parser hostage to our desired future GC demands. Let's 
help him finish his work in the Emacs that we have today and be explicit about 
our assumptions and needs. The proposed code's requirements are not unique, nor 
do the solutions need to be.

> What do I propose: If you can, please make objects reachable from the
> control stack. For instance, create a context object on the stack that
> has a Lisp vector member.

The problem is that with the GC that we actually have, xmalloc/xfree is a lot 
faster than creating a Lisp vector and letting the GC collect it later on.

One possible way out might be providing a way to free a vector ahead of time, 
akin to free_cons, and create a vector type with a fill pointer so that it does 
not need to be initialised nor traversed in full if only part of it is used.

The last part is straightforward, although it complicates vectorlike traversal 
a bit. Ahead-of-time freeing might be unnecessary with a modern collector but 
that needs to be verified.