Bound stack depth from nested parallelism - #9378
Open
abadams wants to merge 2 commits into
Open
Conversation
A thread that stalls waiting on a parallel loop it owns may run tasks from other parallel regions rather than idle. That is worth keeping: with a small inner loop, starting another instance of the outer loop is the only work available. But each one nests a new owned job inside the one already being waited on, and that stack frame cannot unwind until the new job completes, so a single thread could accumulate one frame per outer loop iteration. Track how many of the jobs each thread owns have stalled, in an array indexed by a hash of the thread id, and let a stalled job start work from another region only while its thread is below the limit of two. A thread can still take one more instance of a loop it is already inside, but not an unbounded number of them. Descending without stalling is already bounded, since it can only go one level deeper into the loop nest, so per-thread stack depth is now bounded by the pipeline's static loop nest depth rather than by loop extents. The thread id is only fetched when a job first looks outside its own region, which on Linux costs a syscall. A pipeline whose parallel loops aren't nested never gets that far. Fixes #9377 Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #9378 +/- ##
==========================================
- Coverage 70.08% 70.02% -0.07%
==========================================
Files 260 260
Lines 79287 79287
Branches 19327 19327
==========================================
- Hits 55569 55521 -48
- Misses 17923 17932 +9
- Partials 5795 5834 +39 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
The test defines an extern that the pipeline calls, so the JIT has to find it in the running process. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
alexreinking
approved these changes
Aug 24, 2026
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
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.
A thread that stalls waiting on a parallel loop it owns may run tasks from other parallel regions rather than idle. That is worth keeping: with a small inner loop, starting another instance of the outer loop is the only work available. But each one nests a new owned job inside the one already being waited on, and that stack frame cannot unwind until the new job completes, so a single thread could accumulate one frame per outer loop iteration.
Track how many of the jobs each thread owns have stalled, in an array indexed by a hash of the thread id, and let a stalled job start work from another region only while its thread is below the limit of two. A thread can still take one more instance of a loop it is already inside, but not an unbounded number of them. Descending without stalling is already bounded, since it can only go one level deeper into the loop nest, so per-thread stack depth is now bounded by the pipeline's static loop nest depth rather than by loop extents.
The thread id is only fetched when a job first looks outside its own region, which on Linux costs a syscall. A pipeline whose parallel loops aren't nested never gets that far.
Fixes #9377