[mono][interp] Add tiering within interpreter #68823
Merged
Conversation
This file contains 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
|
Tagging subscribers to this area: @BrzVlad Issue DetailsCompile code initially without optimizations, recompile methods with optimizations enabled once we reach a certain threshold.
|
|
just checking CI for now |
|
Contributes to #63809 |
For a single MonoMethod*, we can have two InterpMethod* instances, one with optimized flag false and the other with true. When tiering is enabled, when first getting an InterpMethod* for a MonoMethod* we set the optimized flag to false. When generatig code for this method, if optimized is false we must emit a special MINT_TIER_ENTER_METHOD at the start and later in the codegen process we skip applying optimizations to method code. MINT_TIER_ENTER_METHOD opcode is invoked with every method start and it will bump a counter. Once we hit the limit, the method will be tiered up. This process consists of creating a new InterpMethod* instance which have optimized set and storing it in the interp_code_hash, changing the mapping from the old MonoMethod. The optimized and unoptimized method use the same argument space, so tiering the method up requires just to set the ip to the start of the tiered up method code. An additional problem that happens with tiering is that we have to replace all instances of the untiered method from generated code. InterpMethod* instances are stored stored inside data_items of other methods and also inside vtables. When generating code for any method, we have to store in a hash table mappings from untiered InterpMethod* instance to addresses where this instance was stored. When we tier up the unoptimized method, we will traverse the list of addresses where this references is stored and update it to the optimized version.
BrzVlad
force-pushed
the
feature-interp-tiering
branch
from
c1cfa79
to
d08542b
Compare
Some optimizations might not be enabled by default, so add option to enable them.
In unoptimized code, we add a patchpoint instruction when entering basic blocks that are targets of backward branches, if the stack state is empty. This means that when tiering up a frame we just need to jump to the equivalent basic block in the tiered up method and execution can continue. Since the arguments and IL locals reside in the same space in both versions of the method (their offsets are computed in interp_method_compute_offsets)
We always take jit_mm lock when finishing compilation of method, use it also for publishing InterpMethod* fields. This also prevents weird races where the method can be tiered up before the we take the jit_mm lock, resulting in publishing the seq_points for the untiered method
Once we emit a tailcall, execution in the current bblock is finished.
We were doing unsigned conversion before
BrzVlad
force-pushed
the
feature-interp-tiering
branch
from
d08542b
to
197a847
Compare
|
/azp run runtime-wasm, runtime-extra-platforms |
|
Azure Pipelines successfully started running 2 pipeline(s). |
BrzVlad
force-pushed
the
feature-interp-tiering
branch
3 times, most recently
from
f11e710
to
58ee025
Compare
… enabled When invoking these clauses we obtained the InterpMethod from the MonoMethod* and make use of the jit info stored during frame unwinding. However, the method might have been tiered up since storing the jit info, so the native offsets stored there will no longer be relative to the optimized imethod. Fetch again the MonoJitInfo* from the imethod that we will be executing.
BrzVlad
force-pushed
the
feature-interp-tiering
branch
from
58ee025
to
1cd24fc
Compare
|
This seems stable and ready for review. I tried running some benchmarks from our own repo and didn't notice any difference. I'm not sure however if there was supposed to be any difference there, given it runs code in a loop and unoptimized compilation wouldn't make an impact. I ran the default blazor wasm sample however and tiering had a great startup improvement (around 20%) (I measured it by doing performance profiling on chrome and checked the scripting time, which was most of the time spent in startup) I would agree with @SamMonoRT that it would be easier to merge with tiering enabled, have more iterations of test suites and benchmarking done automatically, and unset it as default (maybe just for the release) if any problems arise. @lewing Any thoughts on how to proceed with this ? Do you know if blazor runs would pick up these changes relatively soon ? |
|
/azp run runtime-wasm, runtime-extra-platforms |
|
Azure Pipelines successfully started running 2 pipeline(s). |
lewing
approved these changes
May 24, 2022
BrzVlad
force-pushed
the
feature-interp-tiering
branch
from
1cd24fc
to
e1d772e
Compare
radical
added a commit
to radical/runtime
that referenced
this pull request
May 26, 2022
This reverts commit 962a455. Prompted by dotnet#69864
carlossanlop
pushed a commit
that referenced
this pull request
Jun 1, 2022
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Compile code initially without optimizations, recompile methods with optimizations enabled once we reach a certain threshold.