Open SamMonoRT opened 1 year ago
Tagging subscribers to this area: @directhex See info in area-owners.md if you want to be subscribed.
Author: | SamMonoRT |
---|---|
Assignees: | directhex, kotlarmilos |
Labels: | `area-Infrastructure-mono` |
Milestone: | 9.0.0 |
Mono fullAOT linux runtime tests now utilize the new Mariner image. This image does not include binutils, and as a result, GNU as
cannot be used as a native assembler. The AOT compiler utilizes llvm opt
and ilc
to generate the llvm binary file. Then, a native assembler and linker are required to produce the final binary.
One option is to utilize llvm-mc (clang)
, which can convert assembly into a binary object file. However, I am not sure if there's a 1:1 mapping between the llvm-mc
and GNU as
. Another option is to ship binutils with the image.
For linux-arm64, either option would require a cross-compiled toolchain for x64 targeting arm64.
/cc: @directhex @lambdageek
After several attempts to enable fullAOT llvm runtime tests on the extra-platforms, the job consistently hits OOM issue after 2h. To simplify the process, the job compiles only the baseservices/mono
and System.Private.CoreLib
with the maxcpucount
set to 1
.
The CI is using an azure instance with 16gb, docker on top of that is limited to less, probably 8gb. At peak, the AOT compilation takes about 16gb to AOT compile the System.Private.CoreLib
. When I tried to reproduce the issue locally on the cbl-mariner-2.0-cross-amd64
, it completed the compilation successfully within 10min. There is a tracking issue in azdo where we have requested a hardware upgrade https://github.com/dotnet/dnceng/issues/1163.
@steveisok @SamMonoRT While we work on resolving the OOM issue, I would appreciate hearing your thoughts on temporarily disabling the affected jobs to ensure a consistently green CI.
I'm fine with disabling for the time being.
I wonder if requiring so much memory is a sign we can improve our aot compiler utilization?
I wonder if requiring so much memory is a sign we can improve our aot compiler utilization?
Yes, let's create a tracking issue so that we can brainstorm our next steps. Additionally, I'll temporarily disable the failing jobs.
Description
Currently, the Mono fullAOT LLVM jobs are encountering failures and don't provide any test coverage. Specifically, the linux-arm64 job must build the cross-compiler using an image which incorporates both x64 and arm64 rootfs. Additionally, the aot-compiler.c utilizes GNU
as
which is not available since we don't have GNU binutils on the Mariner.To resolve this issue, we have to fix the mono-aot-cross build for linux-arm64 to use target rootfs when building the runtime and host rootfs when building the compiler. After that, the aot-compiler.c has to be updated to use
llvm-as
orclang
instead of GNUas
.Additionally, the AOT compiler with llvm 16 toolchain hits OOM issue with CBL_Mariner images.
Tasks
Initial discussion can be found at https://github.com/dotnet/runtime/issues/86324#issuecomment-1549896743.
Disabled tests
Upon the initial setup of the jobs, the following tests require triage.
FullAOT mini
AOT compilation failure:
Execution failure:
FullAOT LLVM
AOT compilation failure:
Execution failure: