perf: give currRecDepth its own ReaderT layer in CoreM - #14970
Draft
Kha wants to merge 2 commits into
Draft
Conversation
Member
Author
|
!bench |
|
Benchmark results for f409edb against 696e847 are in. There are significant results. @Kha
Large changes (6🟥)
Medium changes (11✅, 1🟥)
Small changes (490✅, 175🟥)
|
github-actions
Bot
added
the
toolchain-available
|
Mathlib CI status (docs):
|
Collaborator
|
Reference manual CI status:
|
…in `lean_apply_m` This PR fixes a crash when more than 16 arguments are applied at once to a closure whose arity is at most 16. Deeply nested monad stacks can produce such applications, and the result was memory corruption rather than a clean call. `lean_apply_m` handles applications of more than 16 arguments. Its over-application branch invoked the closure through `FNN`, which passes arguments as an array. That convention is only correct for closures whose arity exceeds `LEAN_CLOSURE_MAX_ARGS`; below that the generated code takes its arguments separately, so the callee received the argument array in its first parameter and register garbage in the rest. The fixed-arity `lean_apply_N` functions already guard this, `lean_apply_15` even asserting `arity > 16` immediately before its `FNN` call. The over-application branch now applies the first `arity - fixed` arguments via `lean_apply_n`, which dispatches on the count and consumes the closure, and continues with the remainder.
This PR stops the recursion-depth guard from rebuilding `Core.Context` on every recursive step. Roughly 96% of `Core.Context` reconstructions exist only to bump the depth counter, and each one paid a reference count increment per pointer field. `withReader` can never reuse the `Context` record, so keeping `currRecDepth` there made every `withIncRecDepth` rebuild it. As its own reader layer the depth is just an extra argument, so a recursion step neither allocates nor touches a reference count. The layer sits inside the `Context` reader so that a bare `read` still resolves to `Context`, and `CoreM.run` gains an initial-depth parameter so nested command elaboration keeps inheriting its caller's depth. Note this changes `CoreM`'s arity, which is externally observable in LCNF output.
Kha
force-pushed
the
core-recdepth-readert
branch
from
August 29, 2026 19:50
f409edb to
f51ba22
Compare
Member
Author
|
!bench |
|
Benchmark results for f51ba22 against e991a05 are in. There are significant results. @Kha
Large changes (2✅, 5🟥)
Medium changes (30✅, 2🟥)
Small changes (754✅, 65🟥)
|
Member
Author
|
!bench mathlib |
|
Benchmark results for leanprover-community/mathlib4-nightly-testing@3495667 against leanprover-community/mathlib4-nightly-testing@78f2465 are in. There are significant results. @Kha
No significant changes detected. |
github-actions
Bot
added
the
mathlib4-nightly-available
leanprover-bot
added
the
builds-manual
mathlib-lean-pr-testing
Bot
added
the
breaks-mathlib
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
3 participants
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.
This PR stops the recursion-depth guard from rebuilding
Core.Contexton every recursive step. Roughly 96% ofCore.Contextreconstructions exist only to bump the depth counter, and each one paid a reference count increment per pointer field.withReadercan never reuse theContextrecord, so keepingcurrRecDepththere made everywithIncRecDepthrebuild it. As its own reader layer the depth is just an extra argument, so a recursion step neither allocates nor touches a reference count. The layer sits inside theContextreader so that a barereadstill resolves toContext, andCoreM.rungains an initial-depth parameter so nested command elaboration keeps inheriting its caller's depth.Note this changes
CoreM's arity, which is externally observable in LCNF output.