fix(runtime): release deep node chains iteratively #327
Loading…
Reference in a new issue
No description provided.
Delete branch "loop/211-iterative-release"
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 #211
Releasing a long persistent chain (a
ConsStack, the cons lists of aBankersQueue) recursed one C frame per node and overflowed the stack around some tens of thousands of nodes.runtime/memory.c:torb_releaseandtorb_free_countedcount per thread how many drops they are inside of. A block whose last count runs out 256 drops deep goes onto a per-thread pending list, and the outermost release drains it (LIFO). Stack use is bounded, and below the bound the drop andclose()order is unchanged.runtime/machine.c: the VM kernel releases its blocks throughtorb_release/torb_free_countedwith a shape-walking drop function, so the bound holds in both back ends.runtime/panic.c,torb.h: a recovery point saves the depth and the jump restores it. The runtime test harness's panic hook does the same.release-long-chain(BankersQueue and ConsStack of 1,000,000 items, shared tails), tier B, both back ends.BankersQueue.DESTRUCTORS.md2a andVM.mdsection 7 describe the bound.The
.allocationsbudget of the new conformance test is set from the CI count.5e79af7594c0c9f8b872c0c9f8b872315907f857Checklist (head
315907f):release-long-chain(BankersQueue + ConsStack, shared tails, both back ends). CI green for this head (tier A/B, bootstrap, gates, pdisc).torb_drop_and_freedefers at 256 nested drops and only the outermost release (depth 1) drains the list, so nested releases never drain early. A deferred block already has count zero, so nothing can retain it. Recovery points and the test harness hook restore the depth after a longjmp, and the next outermost release drains what is left. The VM kernel now routes throughtorb_release/torb_free_countedwith a shape-walking drop function, so the bound holds in both back ends.BankersQueue; DESTRUCTORS.md 2a and VM.md 7 describe the bound and the close() order caveat past 256 levels.Non-blocking: none.