[release/8.0-staging] [Mono] Fix the race condition issue of aot_module loading #104918
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.
Backport of #103975 to release/8.0
/cc @fanyang-mono
Customer Impact
Prior to this change, Maui Android customer's app would run into
Invalid IL code
error when settingAndroidStripILAfterAOT=true
. The customer's app would either hitInvalidProgramException
or crash completely. The customers reported the issue via #103782 and #104156When setting
AndroidStripILAfterAOT=true
, the IL code for the AOT'ed methods would be removed. As a result, JIT would fail with an error likeInvalid IL code
, if the runtime attempts to do so. Usually, when a method was AOT compiled, Mono runtime would use it instead of attempting to JIT it. What happened to this customer reported scenario was thatmono_aot_get_method
raced withload_aot_module
- one thread attemptted to readMonoImage:aot_module
while the other thread was still loading the aot module.MonoImage:aot_module
contained the information of where the AOT'ed code lives. When it wasn't fully loaded, Mono runtime thought it didn't exist. However, this race condition only happened when two threads were trying to invoke methods from the same assembly, which also happened to be not loaded yet. It is often related to the usage of reflection.Before this PR, there wasn't a way to tell if an aot module was loaded but not found or wasn't loaded at all. This PR introduced a way to differentiate it. Now when
mono_aot_get_method
sees that the aot module wasn't loaded yet, it will wait a little bit and try again.Testing
Manually validated the problematic maui Android app reported in the original issue (#103782). It works correctly now.
Risk
Moderate risk. The race condition that this PR is fixing happens very rarely. So far it only happened to a handful of Maui Android customers. This PR doesn't change the behavior when there isn't a race condition, which is the majority of the case. Additionally, we had monitored microbenchmarks results for two weeks and didn't see any performance regressions caused by this change.