[mono][aot] Enable deduplication of runtime invoke wrappers #84304
Conversation
kotlarmilos
added
area-Codegen-AOT-mono
os-ios
kotlarmilos
requested review from
vargaz,
lambdageek and
SamMonoRT
as code owners
|
Tagging subscribers to 'os-ios': @steveisok, @akoeplinger Issue DetailsThis PR contributes to #83973. It enables deduplication of runtime invoke wrappers on iOS and restricts emitting additional methods into the dedup AOT module that are not collected in the Here are preliminary results comparing size on disk (SOD) and build time between the baseline (main branch) and the target (this branch).
|
|
Tagging subscribers to 'size-reduction': @eerhardt, @SamMonoRT, @marek-safar Issue DetailsThis PR contributes to #83973. It enables deduplication of runtime invoke wrappers on iOS and restricts emitting additional methods into the dedup AOT module that are not collected in the Here are preliminary results comparing size on disk (SOD) and build time between the baseline (main branch) and the target (this branch).
|
|
/azp run runtime-ioslike,runtime-ioslikesimulator |
|
Azure Pipelines successfully started running 2 pipeline(s). |
|
/cc @ivanpovazan |
|
Relevant failing tests indicate that some wrappers are emitted into the dedup assembly during AOT compilation. These wrappers are later retrieved during runtime by the To simplify the build process and improve the SOD, one potential solution is to use @vargaz @lambdageek @ivanpovazan any thoughts on the proposed approach? |
We talked about this briefly during the standup. I think it's a good idea in general to have a uniform approach to where we put "extra methods" during AOT compilation. So it makes sense to me to have a general mechanism in the AOT compiler for emitting the extra methods that doesn't always just hardcode corelib. Separately there's a question of whether corelib could be the destination for all this "extra" stuff when we're in dedup mode. On ios we have to support Mono.framework - which bundles the BCL and its AOT images into something that is shared across apps. In the future, we might want to support dedup of the final app in this sort of compilation, too. In that case we couldn't use corelib as the dedup assembly since it's not going to be per-app. We may want to use the entrypoint assembly as the dedup assembly. Or continue with the current approach of emitting a separate AOT image with dedup content. at AOT runtime we could decide based on whether dedup was used whether to look for wrappers in corelib (if there's no dedup, use the existing behavior), or look for them in the dedup asembly (if dedup was turned on - this would be new behavior). |
|
Thank you for the detailed explanation. After further investigation, I've found that during the AOT compilation of deduplicated methods, the Therefore, it is not possible to restrict the emitting of additional methods into the dedup AOT module that are not collected in the With the deduplication of runtime wrappers only, an additional size saving of approximately 1% to 2% can be achieved on the HelloiOS sample app. Additionally, introducing a dedup state, as you outlined, can improve code maintenance. |
|
/azp run list |
|
No pipelines are associated with this pull request. |
|
/azp run runtime-ioslike,runtime-ioslikesimulator,runtime-wasm |
|
Azure Pipelines successfully started running 3 pipeline(s). |
|
The failures appear to be unrelated. The timeout issue for |
|
We can de-revert this now that vlad's fixes landed, right? |
|
This PR identified the underlying bug and accidentally introduced a regression, so it was reverted. Currently, there is an open PR #85908 that should deduplicate runtime invoke wrappers on iOS. Thanks for the reminder! There is no need for any further actions. |
ghost
locked as resolved and limited conversation to collaborators
This PR contributes to #83973. It improves code maintenance by using deduplication enum instead of multiple flags.
It enables deduplication of runtime invoke wrappers on iOS and restricts emitting additional methods into the dedup AOT module that are not collected in the.dedup_methodshash tableHere are preliminary results comparing size on disk (SOD) and build time between the baseline (main branch) and the target (this branch).Update:
System.Runtimeare failing on theios-arm64CI, even though they pass locally. The failure could be related to missing runtime invoke wrappers during application startup, and the error log may have been masked by a TCP failure. The tests have passed ontvos-arm64, which shouldn't differ fromios-arm64on the CI. Before merging the deduplication of runtime invoke wrappers on iOS, the CI should be updated to report any error logs that occurred during startup. The table with preliminary size savings on iOS has been moved to the tracking issue.