-
Notifications
You must be signed in to change notification settings - Fork 508
[armel] CoreRT Linux/armel progress #4856
Comments
@jkotas is it possible to create group like dotnet/arm32-contrib for involved people? |
Are you using release (or at least checked) build of RyuJIT? I would not expect it to take this long. |
This is awesome progress! Thank you for the update. I have created @dotnet/arm32-corert-contrib . All of you are members except @BredPet who I am not able to add for some reason. I will work on it... |
Thank you! |
I joined. And requested membership in @dotnet/arm32-corert-contrib. |
@jkotas |
I've looked for API calls in Xamarine which could be problematic for CoreRT and have got results below. Checked @jkotas what calls cannot be implemented in CoreRT (if there are such)? Is there any detailed list of API which cannot be implemented? I've looked to https://docs.microsoft.com/en-us/dotnet/framework/net-native/apis-that-rely-on-reflection is it complete? Results:
|
This article explains the main problem with reflection in full AOT tree-shaked environment. A more fine grained list is in https://github.com/dotnet/corefx/wiki/UWP-Compat#systemreflection , but the differences are corner cases that do not cause problems in practice.
The trick with making reflection work is to make sure that whatever the program reflects on gets compiled into the final image. Currently, the CoreRT compiler has a simple logic to keep everything that is statically reachable from the Main method. It can be further customized by rdxml files (look for RdXmlRootProvider), or it is sometimes easier to add a dummy references to parts of the program that should be compiled in. I know Xamarin stack uses custom attributes to opt-in things into reflection. We do not recognize these attributes in CoreRT yet. Check https://developer.xamarin.com/guides/ios/advanced_topics/linker/#Preserving_Code for details. If you run into cases like this, we can work together on figuring out the best way to recognize the Xamarin custom attributes in CoreRT compiler. |
Thank you! |
The large missing features in CoreRT are dynamic loading (loading of binaries that were not seen by the AOT compiler), and Reflection.Emit (it is really just a special case of dynamic loading). There are ways how to make these features work in CoreRT - either by having interpreter, or by using JIT - but it would be a lot of work. |
It looks |
The hard part with this model is versioning (what builds are ok to mix). You typically want to allow mixing and matching of different builds, and doing that for managed code with full AOT is pretty hard because of fragile base class problem. |
OK thank you. It's the same issues like CoreCLR's crossgen has, right? |
Right, the FragileNonVersionable flavor of NGen images. |
@jkotas we've reviewed opened issues. So I want to share tasks which are needed for stable work of CoreRT on ARM. Could you add another tasks if think that it's needed?
Optimizations [25]:
Also there are a lot of other remaining task like testing or build infrastructure. I'm interesting in unimplemented features, API and bugs first. |
Getting CoreRT to work great for everything is a ton of work - I do not think we have even issues opened for all of it. I would help to define the scenario you want to go after first. I assume you want to target relatively simple Xamarin-forms based apps on Tizen. Is this correct? Once there is agreement on the scenarios, we can help you to come up with prioritized list of issues to work on to make it work great. |
@jkotas right, we're focusing on Xamarin based applications from tutorials first. |
For this, I think you should primarily work on these:
|
@jkotas thank you! |
This task is for reporting progress of CoreRT
Linux/armel
support.People are working on it @Dmitri-Botcharnikov @sergign60 @alpencolt @BredPet
Applications
On the latest master we are able to compile and execute Binary-trees, Spectral-norm, Mandelbrot and Fannkuch-redux(without threading version) benchmarks from CoreCLR. ElmSharp Hello Tizen application as well. All apps launched on Samsung Z3 phone
armel cross build on x86 host
It's possible to cross compile application for
armel
on x86 host (or on x64 using rootfs) now.Compilation time for HelloWorld application is reduced from 25 minutes (on Samsung Z3) to 3 minutes on PC. So for compiling all BringUpTests from CoreCLR it's needed about 6 hours (or about 3 days on mobile phone:scream:).
Documentation will be added soon.
BringUpTests from CoreCLR
1 Failed on compilation
11 FAIL
146 SUCCESS
Bug fixing
There are a lot of remaining task and bugs. They will refer to the current task as far as possible.
cc @jkotas @MichalStrehovsky
The text was updated successfully, but these errors were encountered: