refactor: heap-based work stack for hv_clone_iterative#130
Draft
Koan-Bot wants to merge 3 commits into
Draft
Conversation
The previous hv_clone_iterative recursed through sv_clone →
rv_clone_iterative → hv_clone_iterative for each hash-of-hash nesting
level, consuming ~3 C stack frames per level — the same stack pressure
as the recursive path it was meant to replace.
Replace with a heap-allocated work stack that processes (source, clone)
HV pairs iteratively. Values that are RV→HV are handled inline:
the inner HV clone is created, registered in hseen, and pushed onto the
work stack for deferred key iteration. Non RV→HV values still delegate
to sv_clone.
For single-key hash chains {k => \{k => \{...}}}, the work stack stays
at depth 1 regardless of chain length, reducing per-level C stack cost
from ~270 bytes to zero.
Also adds 6 tests for blessed hash chains and weakrefs to hash nodes
past MAX_DEPTH, exercising the new code path.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
install-with-cpm@v1 regressed on Perl 5.8-5.22 after a recent cpm update requiring Perl 5.24+. Bump to @v2 for action-based jobs and use direct `cpm install` in the Docker-based Linux matrix (where cpm is pre-installed). Matches the approach approved by @atoomic in PR garu#120. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Mixed array/hash nesting consumes ~2x stack per level during Perl's recursive SvREFCNT_dec compared to pure-array chains. 2500 mixed levels overflows Windows' 1 MB default stack during cleanup. Use 1250 as the safe limit for mixed structures. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Replace the recursive implementation of
hv_clone_iterativewith a heap-based work stack that processes hash-of-hash nesting without C stack growth.Why
The previous
hv_clone_iterativerecursed throughsv_clone → rv_clone_iterative → hv_clone_iterativefor each hash nesting level, consuming ~3 C stack frames (~270 bytes) per level — the same stack pressure as the recursive path it was designed to replace. For deeply nested hash structures (e.g. 5000 levels on Linux, 2500 on Windows), the "iterative" path was iterative in name only.This matters most on Windows where the 1 MB default stack limits safe depth to ~2600 levels — uncomfortably close to the 2500-level test target.
How
Hash values that are RV→HV are now handled inline: the inner HV clone is created, registered in
hseen, blessed if needed, and its(source, clone)pair is pushed onto a heap-allocated work stack for deferred key iteration. The work stack processes pairs in LIFO order (depth-first). For single-key hash chains{k => \{k => \{...}}}, the stack stays at depth 1 regardless of chain length.Non RV→HV values (plain scalars, RV→AV, etc.) still delegate to
sv_clone.Weakref tracking (
SvWEAKREF) is preserved — weakened hash values are added to the deferred weakening array.Testing
$deep_targetdepth — class preserved at root and past MAX_DEPTH🤖 Generated with Claude Code
Quality Report
Changes: 2 files changed, 193 insertions(+), 20 deletions(-)
Code scan: clean
Tests: passed (OK)
Branch hygiene: clean
Generated by Kōan post-mission quality pipeline