← Back to AILP Home

JIT

The JIT chapter documents how Nitpick programs produce, install, call, and tear down executable code at runtime using the wildx W^X heap and the stdlib/jit.npk helper.

This is the thinnest possible surface: this cycle ships one hand-assembled signature (int32 add(int32, int32)). It is enough to prove the loop closes end-to-end. Generic code emission (a real assembler, multiple signatures, register allocation) is wishlist for a future cycle and is explicitly not documented here as if it were available.

When to reach for JIT

You want… Use
Inline a hot path that's known only at runtime Jit
Specialise a function for runtime constants Jit
Trampolines / shims into FFI you don't have at AOT Jit
Anything compile-time-known regular AOT
Plain data heap with manual free wild
Lots of small allocs freed together Handle
Long-lived references with cycles gc

JIT is for code, not data. Reach for it only when you need the CPU to execute bytes you produced this run. If you're writing a specialising interpreter, a regex compiler, a small DSL, or an FFI shim generator, this is the door. For everything else, the AOT compiler is already doing it better.

When not to reach for JIT

Chapters

  1. README — this page.
  2. wildx lifecyclealloc → write → seal → call → free, viewed through the JIT lens.
  3. The jit.npk helperType:Jit walkthrough, one-signature surface, ownership model.
  4. Safety — what's exempt from the regular checks, what's still enforced, what can still go wrong.
  5. FAQ — recurring questions ("can I patch in place?", "what about ASLR / NX?", "what's the ARM64 story?").

See also

Validation