perf(vm): read a call's chunk metadata from one record #166
argus
Loading…
Reference in a new issue
No description provided.
Delete branch "loop/8-per-chunk-call-record"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #8
What
A call in the VM now reads the callee's chunk metadata from one per-chunk record whose address is computed once, instead of five
header(image, chunk, word)reads that each recomputeheadersAddress + 8 * (chunk * headerWords + word). Second speed step of VM.md section 10 "Speed, the next steps".All in
compiler/src/vm/interpret.trb:recordOf(image, chunk)gives a chunk's header record address (headersAddress + 8 * headerWords * chunk);parametersOf(image, record)the address of its first parameter.headeris now a read fromrecordOf.executeLoopholdsrecord, the running chunk's record: computed on entry to a chunk (.Call,.CallClosure,.CallWitnesstake the callee's record,.Returnthe caller's from the chunk index in the return record) and again wherever the loop takes the image anew (.Kernel,.CallClosure,.CallWitness,.LoadScript, since a grown image has new header storage). Code start, frame words, places start, first parameter, parameter count, witnesses start and task register are read at constant offsets from it.parametersOf(...)instead ofparameterWord(image, callee, ...), which recomputed the header index per parameter word.ensureFrame(registers, calleeBase, record)takes the frame size (and the overflow site) from the callee's record, so a call computes the callee's record once; the callers outside the loop passrecordOf(image, chunk).codeStartOf,noteFrames, the stack-overflow site and the debugger are unchanged.No new native, no syntax change, no
Machineaddition, no seed impact. The emitter is untouched, sotorb ir --bytecodeoutput is identical; the image is laid out at load and never serialized, so the bytecode format and the embedded program's version token do not change.Speed
Not measured here: the worker runs no release build.
fibonacci(30)(VM.md section 8, about 0.19 s) is to be re-measured by #165 against the previous nightly; this PR claims no speed-up.Test
torb format --check compiler/src/vm/interpret.trb->0 of 1 file would change;torb check compiler/src/vm/interpret.trb->12 files, no problems;sh tools/check-commits.sh origin/mainclean.tests/debug/): forge CI of this PR.tools/conformance.sh --vmwithvm-only/and the.workersprograms):ci.ymlruns it on a pull request only when it touchescompiler/src/ir,compiler/src/backend,runtime/,tools/or.forgejo/, so not on this one; it runs on the push of the landed commit to main. Changing that rule is outside this issue.Approved. Checklist for head
1b27d38:tests/debug/, bootstrap, gates). Pure refactor with no behaviour change, so the existing suites are the right tests.recordOf/parametersOfare the same arithmetic as the oldheader/parameterWord(headersAddress + 8*headerWords*chunk,parametersAddress + 8*parameterWords*firstParameter). Therecordlocal is refreshed everywherechunkorimagechange:.Call,.CallClosure,.CallWitness,.Return, and the three image re-takes (.Kernel,.LoadScript, generation checks in the call arms). The closure environment shift (parameters + 8*parameterWords) matches the oldgivenoffset.ensureFramecallers outside the loop passrecordOf(image, chunk). No new stale-image window compared to before.compiler/src/vm/interpret.trb, matches #8; no native, syntax, emitter or seed change. No speed claim, measurement left to #165, as the issue asks.Non-blocking:
vm-only/,.workers, conformance--vm) is skipped on this PR by the path rule inci.yml, though the issue lists it as an acceptance gate. It runs on the push to main after the merge; if it fails there, revert this commit.