Developers can use native AOT experiment to target Windows and Linux ARM64

[agocke]

Right now Native AOT runs on significantly fewer platforms than CoreCLR. We think that extending support to ARM64, which is already supported by CoreCLR, would be useful in identifying costs and benefits of the Native AOT form factor.

We'd like to add compatibility for Windows and Linux ARM64 to the Native AOT experiment and bring the experience closer to traditional CoreCLR form factors.

Work tracking

runtimelab Infrastructure

• [X] Official builds for runtime labs
• [x] Runtime labs all-up publishing

runtimelab Windows, Linux x64 bring-up

• [X] Move CoreRT tests to use CoreCLR testing infra
• [X] Fix test failures
• [X] Run CoreCLR tests
• [x] Fix top test failures

Archive CoreRT Repo

• [X] Mop-up integration CoreRT -> runtimelabs
• [X] Move documentation from dotnet/corert
• [X] Archive CoreRT

Improve reflection experience

• [X] IL linker annotation support

Debugging

• [x] Infrastructure for more SOS support
• [x] DumpLog, DumpHeap, VerifyHeap and DumpAsync commands

ARM64 Compatibility

• [x] Linux ARM64 build
• [x] Test infrastructure (packaing tests on build machine and execute them on Linux ARM64 box)
• [x] Linux ARM64 smoke tests
• [x] Fix top test failures
• [x] Windows ARM64 build
• [x] Windows ARM64 smoke tests
• [x] Windows ARM64 fix top test failures

Improved Linux tracing

• [ ] Finish refectoring EventPipe to be shared between CoreCLR and Mono
• [ ] Integrate new EventPipe implementation into Native AOT

[agocke]

cc @jkotas @MichalStrehovsky

[jeffschwMSFT]

@agocke can you parent this under the right theme

[agocke]

@jeffschwMSFT Since this is a User Story, I added it to the https://github.com/dotnet/runtimelab/issues/248 Epic. Does that look right to you?

[charlesroddie]

ARM64 support is great but there is a lack of a user story here to match the ambitions of the title ("widen platform compatibility").

Here are some major .Net platforms with the current state of support:

Platform	AOT support in .Net	Work for nAOT support	Estimate
Windows GUI (UWP/WinForms/WPF/Avalonia)	No (Avalonia only; UWP is regression)	COM interop	Medium
Xamarin Mac/iOS	Partial via mono	ARM64 + hooks	Large
Xamarin Android	Partial via mono	ARM64 + hooks	Large
Blazor client	Planned for mono	WASM + hooks	?
Traditional web (ASP.Net/Blazor server)	No	Reflection-free web frameworks	Large?

[agocke]

We use the term "platform" to refer to OS+arch, these are what I would call "app frameworks"

At the moment we're not working on broadening app framework support, but focusing on traditional command line-like apps, while broadening support for more underlying platforms.

[danmoseley]

@agocke we are trying to fix all user story titles to be in terms of the user visible result. Is this a reasonable title: "Developers can use AOT to target Windows and Linux ARM64" ?

[jkotas]

"Developers can use AOT to target Windows and Linux ARM64"

Developers can use native AOT experiment to target Windows and Linux ARM64

[charlesroddie]

At the moment we're not working on broadening app framework support, but focusing on traditional command line-like apps

It's valid to substitute "irrelevant" for "traditional command line-like" in the above sentence and it shows that he strategy is insane. There was a native aot framework (UWP), which was deployed in user-facing apps, has regressed with dotnet5, and you are saying that even after significant future development native AOT will still be unusable in practice.

[christianscheuer]

So happy with the direction this is all going in. Just a quick question from a customer who's been very happy with CoreRT on Intel Macs so far (and so are all of our customers in turn). Is there a particular reason why macOS was left out of this story?

[jkotas]

The scope of this user story is tailored to the needs of customers we are working closely with on this project.

Once we have Windows and Linux ARM64 and macOS ARM64 works in mainline CoreCLR, I should be fairly trivial to enable macOS ARM64 as well. We will be happy to accept PR with the required changes and provide guidance along the way.

[christianscheuer]

Thank you, Jan! Really appreciate it.

[Symbai]

At the moment we're not working on broadening app framework support, but focusing on traditional command line-like apps, while broadening support for more underlying platforms.

Does this mean the whole AOT thing here is just working for console applications and not for WPF application? If the answer is simply "yes" then I could save a lot of time wasting to read all guides, digging myself through the build process and fail on testing AOT on my WPF application.

Also if the answer is "yes" you might leave a note here: https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/docs/workflow/building/coreclr/nativeaot.md

[vitordelucca]

We use the term "platform" to refer to OS+arch, these are what I would call "app frameworks"

At the moment we're not working on broadening app framework support, but focusing on traditional command line-like apps, while broadening support for more underlying platforms.

Is this still the idea? UWP is unusable without AOT. So this basically means developers who want performant UWP apps will need to use other frameworks than .NET?

[lukemcdo]

Would like to have it noted whether the resulting output binaries are also targeted for Alpine, or depend on glibc somehow. I assume that Alpine would be supported.

[jkotas]

Would like to have it noted whether the resulting output binaries are also targeted for Alpine, or depend on glibc somehow. I assume that Alpine would be supported.

We just enabled Alpine builds. Please give it a try and file issues on any problems you run into.

The resulting binaries depend on either glibc or musl (same as regular .NET runtime), so you have to have a different native binary for Alpine ie dotnet publish -c Release -r linux-musl-x64.

[agocke]

This work appears to be largely complete, modulo any bugs we find