[MicroPerf] Perf: eliminate per-call closure in StackGuard.Guard via InlineIfLambda - #20368
Open
T-Gro wants to merge 3 commits into
Open
[MicroPerf] Perf: eliminate per-call closure in StackGuard.Guard via InlineIfLambda#20368T-Gro wants to merge 3 commits into
T-Gro wants to merge 3 commits into
Conversation
StackGuard.Guard was called at 18 hot compiler sites as `guard.Guard <| fun () -> body`, allocating a heap closure for the `fun () -> body` on EVERY call even though the common path just runs `f ()` inline. This was the #1 allocator in the compiler (remapExprImpl guard closure alone ~312 MB/compile of a 65k-LOC input). Make Guard an `inline` member with `[<InlineIfLambda>] f`, so the fast path inlines the body (zero closure). The rare stack-insufficient path (metrics + async SwitchToNewThread) moves to a non-inline `RunOnNewStack` member so the heavy code isn't duplicated at call sites. Depth accounting moves to non-inline `EnterGuard`/`ExitGuard` members so the inlined body touches no private field (realsig-safe; no FS1113). Since the `<|` operator defeats InlineIfLambda, the 12 `<|` call sites are converted to direct-call `Guard(fun () -> ...)` syntax; the 4 existing direct-call sites benefit unchanged. Result on a 65k-LOC compile (Release, net11): total allocation 10630.7 -> 9979.0 MB/compile (~651 MB, 6.1% saved); the guard closures remapExprImpl@1749 (312 MB), accFreeInExprNonLinear@1099 (105 MB), OptimizeExpr@2519 (59 MB), accExpr@45 (40 MB), TransExpr@1130 (20 MB) all drop to 0. Emitted output is byte-identical (IL disassembly 0 diffs; single-file outputs hash-identical). Deep-recursion behavior preserved: 200000-deep guarded recursion still jumps threads (73 jumps) and completes with no Field/MethodAccessException under --realsig+. IL size delta +85.5 KB (+0.41%). Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
T-Gro
added
the
NO_RELEASE_NOTES
github-actions
Bot
added
the
AI-Tooling-Check-Bypassed
Contributor
|
T-Gro
changed the title
T-Gro
enabled auto-merge (squash)
August 27, 2026 08:29
T-Gro
force-pushed
the
t-gro-stackguard-closure-spike
branch
from
August 27, 2026 08:40
10f431e to
17d2321
Compare
…seline) EmittedIL/Inlining baseline (StackGuardInlineIfLambda.fs + .il.bsl) over a vanilla StackGuard emulation: inline Guard + [<InlineIfLambda>] + a separate non-inline RunOnNewStack the lambda is handed to, guarded by RuntimeHelpers.TryEnsureSufficientExecutionStack (as in the real StackGuard). The baseline pins that `callDirect` (direct application) inlines the lambda on the common path with the closure `newobj` confined to the cold else-branch, while `callPiped` (`<|`) hoists the `newobj` to method entry. A regression that reintroduces a common-path allocation changes callDirect's IL and fails the baseline. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 4862d2e9-7740-4d0b-ba96-113e99466711
T-Gro
force-pushed
the
t-gro-stackguard-closure-spike
branch
from
August 27, 2026 08:51
17d2321 to
1aec61a
Compare
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.
StackGuard.Guardallocated a heap closure for itsfun () -> bodyargument on every call at 18 hot sites, even though the common path just runsf ()inline. MadeGuardaninlinemember with[<InlineIfLambda>] f; the cold path (new-thread jump) moved to a non-inlineRunOnNewStack, depth accounting to non-inlineEnterGuard/ExitGuard(realsig-safe, no private-field access from inlined body). The 12Guard <| fun () -> …sites becameGuard(fun () -> …)soInlineIfLambdacan fire (see note).Closure allocation, 65k-LOC input, Release/net11 (MB per compile):
remapExprImpl@1749exprF@559(ExprFolders)accFreeInExprNonLinear@1099OptimizeExpr@2519accExpr@45TransExpr@1130≈ 651 MB/compile (−6.1%).
Per-call microbench (
GC.GetAllocatedBytesForCurrentThread, 1M calls):Guard(fun () -> …)inlineGuard <| fun () -> …Emitted output byte-identical (IL disassembly 0 diffs; single-file
--deterministic+outputs hash-identical). Deep recursion still jumps threads (200000-deep → 73 jumps, noFieldAccessException/MethodAccessExceptionunder--realsig+).FSharp.Compiler.Service.dll+85.5 KB (+0.41%).Regression test (
EmittedIL/Inlining/StackGuardInlineIfLambda.fs+.il.bslbaseline): a vanillaStackGuardemulation (inlineGuard+[<InlineIfLambda>]+ separate non-inlineRunOnNewStackthe lambda escapes into) pins thatcallDirectinlines the lambda on the common path with the closurenewobjconfined to the cold else-branch, whilecallPiped(<|) hoists it to method entry.