You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[wasm][aot] Link step failing for Microsoft.Extensions.Logging.Generators.Roslyn3.11.Tests - wasm-opt getting killed #51961
changed the title [-][wasm][aot] `wasm-opt` fails for `System.Text.Json.Tests`[/-][+][wasm][aot] `wasm-ld` fails for `System.Text.Json.Tests`[/+]on Jun 15, 2021
The job in question runs on Helix on a bare D2a_v4 Azure VM (2 cores of AMD Epyc, 8GB RAM)
Serializing the build, and using a less-memory-intensive compiler optimization level are about the best we can do to reduce the memory usage, and we already do them
The Clang compile stage requires 7.8 gig of RAM. If it's failing on the clang step in CI, then other basic OS stuff on the VM is likely using enough RAM that Clang can't get the 7.8 gig it wants
The final step of the build, the call to wasm-opt, requires more memory than Clang - 8.5 gig.
The problem is AOTing roslyn, a linked Microsoft.CodeAnalysis.CSharp.dll still contains 30k methods, AOT creates 80k methods out of this because roslyn contains a lot of valuetypes causing a lot of generic instances to be added, running the aot compiler on this assembly alone takes 40 seconds, the .bc -> .o step takes 10 minutes (!).
mono_trace (G_LOG_LEVEL_DEBUG, MONO_TRACE_AOT, "AOT: Module %s is unusable because a dependency is out-of-date.", assembly->image->name);
if (mono_aot_only)
g_error ("Failed to load AOT module '%s' while running in aot-only mode because a dependency cannot be found or it is out of date.\n", found_aot_name);
Activity
vargaz commentedon May 6, 2021
This probably happens because the code is just too big.
radical commentedon Jun 10, 2021
The current failure:
[-][wasm][aot] `wasm-opt` fails for `System.Text.Json.Tests`[/-][+][wasm][aot] `wasm-ld` fails for `System.Text.Json.Tests`[/+]lewing commentedon Jun 28, 2021
This should be fixed by #53603 and the flto changes
27 remaining items
directhex commentedon Jan 20, 2022
Okay. Findings:
wasm-opt, requires more memory than Clang - 8.5 gig.vargaz commentedon Jan 20, 2022
The problem is AOTing roslyn, a linked Microsoft.CodeAnalysis.CSharp.dll still contains 30k methods, AOT creates 80k methods out of this because roslyn contains a lot of valuetypes causing a lot of generic instances to be added, running the aot compiler on this assembly alone takes 40 seconds, the .bc -> .o step takes 10 minutes (!).
vargaz commentedon Jan 20, 2022
We might want to add some functionality to the build system to exclude certain assemblies like roslyn from AOTing.
radical commentedon Jan 20, 2022
We do have that, as a hack (https://github.com/dotnet/runtime/blob/main/src/tasks/AotCompilerTask/MonoAOTCompiler.cs#L488-L489).
directhex commentedon Jan 20, 2022
So what's the play, try to shoehorn the test as-is onto Helix, or try to wire up the AOT skip?
vargaz commentedon Jan 20, 2022
I'd suggest skipping AOTing for these assemblies, they take forever to AOT which also impacts CI performance even if it works.
directhex commentedon Jan 21, 2022
I skipped AOT, and I have no idea how to parse this failure https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-63958-merge-c3e46af019234e5a83/normal-Microsoft.Extensions.Logging.Generators.Roslyn3.11.Tests/1/console.0b1eb581.log?sv=2019-07-07&se=2022-02-10T15%3A15%3A41Z&sr=c&sp=rl&sig=uuwgEA0aSi%2BkNV%2BWkslo%2FBLzkvgx4guydgtVeRkyidQ%3D
directhex commentedon Jan 21, 2022
Failure is at
runtime/src/mono/mono/mini/aot-runtime.c
Lines 2300 to 2303 in 9c8b804
vargaz commentedon Jan 24, 2022
Is there a PR which skips the AOT step for these assemblies ?
vargaz commentedon Jan 24, 2022
An alternative would be compiling with O1, i.e.:
Running with this reduced the total runtime from 16 minutes to 11 minutes on my machine, it might solve the OOM problem as well.
directhex commentedon Jan 24, 2022
vargaz commentedon Jan 25, 2022
#64294
elinor-fung commentedon Feb 17, 2022
@directhex @radical - the latest rolling build (which has #63958) still hit this.
Still looks to be an OOM, but I don't know how to get more information about the exact cause.