Sprint 283: In-Memory JIT Compilation & Executable Machine Code ⚡
Welcome to Sprint 283 and 291! In this blog post, we dive deep into the newly implemented KnotenCore JIT compilation layer. To achieve maximum computational efficiency for autonomous AI agents, we now translate AST expressions directly into raw x86_64 machine assembly instructions in memory and execute them directly on the host CPU.
🧠 Dynamic Allocation of RWX Memory Pages
Modern operating systems restrict execution of instructions from default data regions like the heap or stack for safety reasons (known as W^X: Write XOR Execute). To execute JIT-compiled assembly, we must explicitly request an executable memory region from the OS kernel.
In Sprint 283, we achieved this using the memmap2 crate:
- Allocate an anonymous memory page via
MmapMut::map_anon(size). - Copy the raw byte stream of generated x86_64 opcodes into this page.
- Make the allocated page executable using
make_exec(). - Transmute the pointer of the executable page into a Rust function pointer (
extern "C" fn() -> i64) and execute it.
🛠️ Register Fixes & Test Hardening (Sprint 291)
During our Sprint 290 audit, we discovered that JIT additions pushed the wrong register back onto the stack. Although add rcx, rax executed successfully (placing the sum in `rcx`), the JIT compiler pushed `rax` (the unmodified left operand) instead.
In Sprint 291, this was rectified by adding `emit_push_rcx` to push `rcx` (`0x51`) instead of `rax`. We also added the dedicated test test_jit_native_execution_add to verify that compiling and executing `10 + 5` directly on the host CPU yields precisely `15`.
🧪 Verification & Performance Impact
By executing machine instructions directly inside native memory pages, we bypass interpreter loop branching and FFI boundaries, achieving native bare-metal execution speeds. The test suite verifies the JIT emitter pipeline on every check-in to ensure robust, panic-free compiler performance.