Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 1 addition & 13 deletions .jules/bolt.md
Original file line number Diff line number Diff line change
@@ -1,13 +1 @@
## 2026-08-19 - Removed redundant instruction array lookup in VM loop
**Learning:** The inner loop of the VM interpreter (`execute_loop`) had an expensive, redundant deep indexing operation to fetch `inst_operands` which was already available on the `inst` reference. Re-fetching it via `self.module.functions[...].chunk.instructions[...].operands` adds unnecessary bounds checks and pointer chasing in the hottest part of the VM.
**Action:** Always prefer using existing local references over redundant deep lookups, especially in tight loops like an interpreter fetch-decode-execute loop.
## 2026-08-19 - Reused local frame and func references in VM opcodes\n**Learning:** The VM executor repeatedly looked up the current frame via `self.frames.last()` and current function via `self.module.functions[...]` in several opcodes (LoadConst, FieldLoad, StoreLocal, etc.). This adds unnecessary bounds checking and pointer dereferencing on the hottest path since `frame` and `func` are already computed at the start of the while loop iteration.\n**Action:** Always reuse existing local references in tight loop opcodes rather than repeatedly querying collections or stacks when the target element is already known and borrowed.
## 2024-05-18 - Rust lifetime limits reuse of mutably borrowed locals in hot VM loop
**Learning:** In `runtime/vm/src/executor.rs`, the main interpreter loop `execute_loop` defines variables `frame` and `func` for the current execution frame and function. While avoiding redundant deep indexing (e.g. `self.frames.last_mut().ok_or(VMError::StackUnderflow)?;`) inside match arms for `Opcode::Jump`, `Opcode::JumpIfTrue`, `Opcode::JumpIfFalse`, `Opcode::Try`, and `Opcode::EndTry` by reusing the existing local `frame` variable reduces bounds checks and overhead, this local `frame` reference cannot be reused inside other match arms like `Opcode::Return` without triggering severe Rust borrow checker issues (e.g., cannot call `self.frames.len()` while `self.frames` is mutably borrowed via `frame`). The previous implementation relied on Non-Lexical Lifetimes (NLL) implicitly ending the borrow of `frame` before reaching opcodes that needed to borrow `self.frames` again. Removing the redundant inner lookups caused the compiler to extend the mutable borrow across the entire loop iteration if not careful, but safely removing them just from control flow opcodes where no further frame manipulation is needed works correctly.
**Action:** Be extremely cautious when extending the lifetime of mutable borrows (especially on central state like a call stack) across large `match` blocks in Rust interpreters, as even correct performance optimizations can easily introduce fatal compilation errors if the borrow inadvertently overlaps with other mutable or immutable accesses.
## 2024-05-18 - Removed redundant clone of VM stack during trace logs
**Learning:** In `runtime/vm/src/executor.rs`, the debugging instruction trace `self.debugger.trace_instruction` was cloning the entire VM stack using `&self.stack.get_dump()` for every single instruction executed. This caused significant `O(N)` overhead inside the main fetch-decode-execute loop just to format debug output. A new `data_slice()` method was added to `ValueStack` to provide zero-copy slice access (`&[RuntimeValue]`) instead, completely eliminating the allocation overhead.
**Action:** Always scrutinize deep clones in logging, tracing, or hot path loops. Use slice references (`&[T]`) instead of `Vec::clone` when the caller only needs read-only access to a collection.
## 2024-06-25 - Suboptimal Line Search in LSP
**Learning:** Using `chars().nth()` with a byte offset (such as one returned by `.find()`) inside a loop over a string creates an O(N) penalty and may result in an incorrect character lookup if multi-byte unicode characters are present.
**Action:** Use string slicing with the byte index to create a subset string slice, and call `.chars().next_back()` or `.chars().next()` on it for an O(1) and UTF-8 safe boundary lookup.
<<
Loading