[mono][interp] Add max limit to the imported IL when inlining #121580
Conversation
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
Contributor
|
Tagging subscribers to this area: @BrzVlad, @kotlarmilos |
Contributor
There was a problem hiding this comment.
Pull Request Overview
This PR adds a maximum limit on the total amount of IL code imported during method compilation in the Mono interpreter to prevent excessive inlining. Without this limit, methods with many inlineable callsites could result in extremely bloated code, causing significant memory usage and slow compilation times.
Key Changes:
- Introduces a 1MB budget (1,000,000 bytes) for total imported IL code during compilation
- Tracks accumulated IL size across all inlining operations
- Prevents further inlining once the budget is exceeded
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
src/mono/mono/mini/interp/transform.h |
Adds total_il_size field to TransformData struct to track cumulative imported IL |
src/mono/mono/mini/interp/transform.c |
Implements budget constant (1MB), budget check in inlining heuristic, IL size tracking in code generation, and proper save/restore of counter during inlining attempts |
vitek-karas
reviewed
Nov 13, 2025
This was referenced Nov 13, 2025
Open
kotlarmilos
approved these changes
Nov 14, 2025
f9a616f to
f30dccd
Compare
While we have some simple heuristics on whether we should inline a method or not, we have no limit on how many methods we can inline. So, if a method has 1000 callsites to methods that are inlineable, we will inline each one of them, significantly bloating the code. This is made worse by more advanced SSA optimizations, because the compilation time becomes very slow and uses a lot of memory. The limit is set as a simple upper limit on the total amount of IL code being imported as part of method compilation. This is set to a generous initial value of 1MB, since local testing showed that it is still handled decently well. The largest value obtained from running System.Runtime libtests suite is 100K. A customer provided sample was hitting 8MB of imported code, which was causing GBs of mem usage and several seconds to compile the method. In the end, all this code was discarded anyway, since it was exceeding interpreter offset limits, and we had to retry compilation with inlining disabled.
f30dccd to
b96da03
Compare
Member
Author
|
/ba-g wasm failure unrelated |
Member
Author
|
/backport to release/10.0 |
Contributor
|
Started backporting to |
2 tasks
jeffhandley
pushed a commit
that referenced
this pull request
Jan 8, 2026
…nlining (#122588) Backport of #121580 to release/10.0 /cc @BrzVlad ## Customer Impact - [x] Customer reported - [ ] Found internally Mono interpreter didn't have a limit for stopping inlining. Huge methods calling methods that can be inlined would lead to even more code bloat. This can result in GBs of mem used for method compilation and seconds taking to compile the method, or simply an out of memory crash. Targets using mono interpreter (wasm + ios) can be impacted. ## Regression This behavior is not technically a regression, however it is more of a problem with more advanced compiler optimizations (added from NET9+), which end up using significantly more memory / processing time. ## Testing Tested on sample provided by customer. ## Risk Low. The fix just disables inlining after a certain code growth. Co-authored-by: Vlad Brezae <brezaevlad@gmail.com>
This was referenced Jan 9, 2026
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 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.
While we have some simple heuristics on whether we should inline a method or not, we have no limit on how many methods we can inline. So, if a method has 1000 callsites to methods that are inlineable, we will inline each one of them, significantly bloating the code. This is made worse by more advanced SSA optimizations, because the compilation time becomes very slow and uses a lot of memory.
The limit is set as a simple upper limit on the total amount of IL code being imported as part of method compilation. This is set to a generous initial value of 1MB, since local testing showed that it is still handled decently well. The largest value obtained from running System.Runtime libtests suite is 100K. A customer provided sample was hitting 8MB of imported code, which was causing GBs of mem usage and several seconds to compile the method. In the end, all this code was discarded anyway, since it was exceeding interpreter offset limits, and we had to retry compilation with inlining disabled.