Interest in reviving quickjit-style JIT for quickjs-ng?

[MohammadRaziei]

Hi @bnoordhuis,

I came across [quickjit](https://github.com/bnoordhuis/quickjit), your experiment from October 2023 that adds JIT compilation to QuickJS by translating bytecode to C and compiling it on the fly with tcc. It looks like a really elegant approach — sidestepping the need for a hand-written native code generator by leaning on tcc as the backend.

I noticed it only had about two weeks of commits before development stopped, and since you're one of the maintainers here on quickjs-ng, I wanted to ask directly rather than guess:

1. Was there a specific reason work on quickjit stopped — e.g. concerns about the runtime-C-compilation approach (security/sandboxing of compiling arbitrary generated C at runtime, maintenance burden of vendoring tcc, portability across platforms), or was it more just a lack of time/priority?
2. Is there any interest from the quickjs-ng side in a JIT along these lines, given how much the bytecode and internal structures have evolved since the original quickjs fork?
3. If someone (e.g. me) wanted to attempt porting the quickjit approach on top of quickjs-ng as a separate/experimental project, is there anything you'd flag up front as a likely dead end, or any design decisions from quickjit you'd do differently today?

Not asking for a commitment to build this into quickjs-ng itself — mainly want to avoid re-treading ground that's already been explored and rejected for good reasons, and would value any pointers before sinking time into it.

Thanks!

[saghul]

He posted why he thought that was a dead end some time ago here in the bug tracker. I cannot find it now, maybe you can.

[bnoordhuis]

#659 (comment) but, in a nutshell, just template jit-ing code alone doesn't give much of a boost, you also need type feedback, inline caches, and hidden classes.

(And, if I did a from-the-ground-up rewrite, I'd probably also switch to a register VM and mark & sweep garbage collection.)