quickjs-jit 0.12.4

JIT-enabled high level bindings to the QuickJS JavaScript engine
Documentation
# gpui-component integration candidate

This directory contains an applicable patch for the real sibling
`gpui-component` checkout. It is deliberately stored here because that checkout
is outside the writable scope of this task.

Apply from the sibling root:

```sh
patch -p1 < ../rquickjs/integrations/gpui-component/rquickjs-jit.patch
cargo test -p gpui-shell --release \
  tests::benchmark::jit_does_not_change_snapshot_or_render_count -- --exact
```

The patch:

- switches the shell to the published `quickjs-jit` distribution, enables a
  native-default, non-Wasm `quickjs-jit-runtime` dependency, and retains
  the ordinary interpreter runtime as an explicit benchmark mode;
- owns `JitRuntime` for the full QuickJS context lifetime and polls bounded JIT
  maintenance only after `Context::with` releases its lock;
- logs one warning and falls back to the interpreter when JIT attachment is not
  available;
- compares real GPUI panel snapshots and script-render counts across modes;
- emits exactly one JSON sample per test process. The repository runner starts
  five discarded warmup pairs and 30 interleaved fresh-process pairs before
  applying the statistical acceptance gates.

Local validation used a clean source copy in `/tmp` plus a symlink preserving
the expected sibling layout. The release build and snapshot/render-count test
passed, as did focused real event, asynchronous continuation, imported-module
reload, and runtime teardown tests.

Two diagnostic pairs are intentionally not publishable performance evidence,
but validate the harness before the required multi-process run. After rebuilding with the bounded
Tier2-after-demotion policy, the suitable JS-heavy numeric layout kernel in the
real render path measured 4.271 ms interpreted versus 0.107 ms automatic, a
39.80x steady-state speedup. Automatic installed two entries and sustained 112
Tier2 entries after five rejected Tier1 trials and one interpreter demotion,
with no deopts or fallbacks. After moving bounded JIT maintenance from every
low-level context entry to one outer render completion, the host-heavy 443-node
panel measured 0.822 ms interpreted versus 0.834 ms automatic: a 1.50%
steady-state regression, while P99 improved by 0.63%. Unsupported functions
were attempted once before measurement and all six measured metric windows
were stable; no native entry, deopt, or fallback occurred.
Both pairs retained identical checksums, snapshot SHA-256 values, and 116
script renders, and the focused parity test passed. Both diagnostic thresholds
pass. Do not publish fixture, forced-tier, or single-pair results in place of
the required confidence-bounded run.

The required frozen-binary run (five discarded warmup processes and 30 paired
fresh processes per workload) is recorded in
`benchmarks/results/gpui-shell-jit-v1.{json,md}`. Every process is pinned to
one selected CPU (`GPUI_SHELL_JIT_CPU`, default `0`), then records 500
identical renders with the true nearest-rank P99. Reload records the median of
five fresh module-generation observations and retains suspend, module
evaluation, instantiation, render, and deferred-resume phase timings in each
raw sample; no observation is discarded.

The current evidence passes every strict gate: the host-heavy panel's P99 CI
is -7.21%..+2.74%, first-window is -0.77%..+0.44%, and hot reload is
-3.37%..+0.84%. The suitable numeric layout workload is 39.82x..40.19x with
16,835 native entries and zero fallback. Checksums and script-render counts
match in all 30 pairs.

The exact external write required is permission to modify these sibling files
and refresh its `Cargo.lock`:

- `Cargo.toml`
- `crates/shell/Cargo.toml`
- `crates/shell/src/engine/quickjs/mod.rs`
- `crates/shell/src/tests/benchmark.rs`
- `Cargo.lock` (generated by Cargo after applying the patch)