Experimental: Add SLJIT JIT compiler integration for QuickJS#1332
Draft
stevefan1999-personal wants to merge 1 commit intoquickjs-ng:masterfrom
Draft
Experimental: Add SLJIT JIT compiler integration for QuickJS#1332stevefan1999-personal wants to merge 1 commit intoquickjs-ng:masterfrom
stevefan1999-personal wants to merge 1 commit intoquickjs-ng:masterfrom
Conversation
This was referenced Feb 9, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is an experimental, simple and primitive SLJIT based JIT engine for QuickJS. aided with help of a LLM. Assume that it is 64-bit only, despite some 32-bit code is in-place, but there is no test for that.
Why?
I really, really want to have a fast JS engine that is fast and tiny...As small as LuaJIT. For a long time. I don't like JavaScriptCore because it does not have good universal support, and it is still on the level of thousands of lines, if not million lines unlike the V8 monster.
Also did this just out of curious. I can always just implement the JIT myself, in fact, I tried to do one before but there are so many opcodes it is getting very mechanical to convert all the C code from QuickJIT to SLJIT
How did you do that?
I just dumped the source code of QuickJIT, SLJIT, the experience of my previous attempts at it manually, and let Opus 4.6 figure out the rest. Indeed Opus has guessed most of the arithmetics right (without revealing Opus what I did), but the suggestions of using icall to get a simpler JIT approach -- seems like it backfired.
Experimental result
Unsurprisingly, the JIT code was slower than that of in interpreter mode, reported by Opus:
Besides from the huge boost of Crypto benchmark, it is a total disaster for the rest. Clearly we need some more optimization. At the same time, SLJIT has a backend for PCRE. Maybe we can port the regex engine of SLJIT here for some good score improvement.
I've also instructed Opus to figure out more optimization for me, one of which is inline variable caching, it claims to learn this from V8, but I need
someone professional in compiler to verify that claim. Indeed it is a valid optimization technique and it boosted performance quite a lot.What's next?
Obviously, the code from LLM has a lot of repetitive part, and needs a lot of fixup..the main JIT is 3000 lines, and as usual LLM manner, it is a total mess. One of the most obvious hot path is to rewrite most, if not all helper code into SLJIT inlined code. This is where most of the performance improvement for integer came first.
I did not intend for it to be merged due to the concern of involving of LLM, after all, as the bias of LLM-generated code is often being nitpicked for being "AI-slop" (well whether LLM is really AI is another problem), but I think it is absolutely right you still need a human to fully verify the code generated first. I'm 99% sure there are some fishy stuff that is not