Xamarin.Mac AOT Prototype

2»

Posts

  • FelixDeimelFelixDeimel ATMember ✭✭

    I also made sure my MONO_PATH points to the Xamarin.Mac framework path if that matters.

  • ChrisHamonsChrisHamons USXamarin Team Xamurai

    Try AOT compiling using /Library/Frameworks/Xamarin.Mac.framework/Commands/bmac-mobile-mono instead of system mono.

    I'll explain what i think is going on in a second...

  • ChrisHamonsChrisHamons USXamarin Team Xamurai

    When you build a Xamarin.Mac application, one of the steps to to link mono into your launcher application. We use the libraries stored here:

    /Library/Frameworks/Xamarin.Mac.framework/Versions/Current/lib/libmono*

    Which is very very likely a slightly different version that your system mono.

    As you can see we ship and use a different mono (which is poorly named) when we AOT XM:

    https://github.com/xamarin/xamarin-macios/blob/master/tools/mmp/aot.cs#L276

  • FelixDeimelFelixDeimel ATMember ✭✭

    @ChrisHamons Same problem unfortunately...

  • ChrisHamonsChrisHamons USXamarin Team Xamurai

    Ok, let's lay out the problem.

    • You have a 64-bit Xamarin.Mac 4.5 Target Framework "main" application
    • You have a .NET library that you dynamically load and want to AOT and have that loaded

    And you are doing the following?

    • Enable AOT on your XM settings
    • Using something like MONO_PATH=/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/lib/mono/4.5/ /Library/Frameworks/Xamarin.Mac.framework/Commands/bmac-mobile-mono to AOT your library
    • Linking the .o files into a dylib
    • Before loading the assembly, you dlopen that assembly, find mono_aot_module_hello_info equivalent, and calling mono_aot_register_module with it?

    Are you getting the same error?

  • FelixDeimelFelixDeimel ATMember ✭✭

    Chris, that's exactly what I'm doing, except for "Enable AOT on your XM settings". I'm not sure what XM setting you're referring to.

  • ChrisHamonsChrisHamons USXamarin Team Xamurai

    Are you AOT'ing your Xamarin.Mac output by hand? Or are you just AOTing the plugins and not your main application?

  • FelixDeimelFelixDeimel ATMember ✭✭

    Yes, I'm only AOTing my plugins, not the main app.
    This is what I'm executing in a terminal: MONO_PATH=/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/lib/mono/4.5 /Library/Frameworks/Xamarin.Mac.framework/Commands/bmac-mobile-mono --aot=static DependencyLibrary.dll

  • ChrisHamonsChrisHamons USXamarin Team Xamurai

    Hmm. Are you still getting the same error:

    error: * Assertion at /Users/builder/data/lanes/4466/a04678c2/source/xamarin-macios/external/mono/mono/mini/aot-runtime.c:2300, condition 'info->version == MONO_AOT_FILE_VERSION' not met

  • FelixDeimelFelixDeimel ATMember ✭✭

    Yep, just checked again.

  • FelixDeimelFelixDeimel ATMember ✭✭

    If we can switch to email, I'd be happy to share my sample project.

  • ChrisHamonsChrisHamons USXamarin Team Xamurai

    Sure. I'll message you it.

  • ZoltanVargaZoltanVarga USXamarin Team Xamurai

    Are you passing the value of the 'mono_aot_module_..._info' symbol to mono_aot_register_module () ? If you are loading it using dlsym (), you need to do an additional indirection, i.e.

    void **addr = dlsym ("....");
    mono_aot_register_module (*addr);

  • FelixDeimelFelixDeimel ATMember ✭✭

    That gets rid of the crash! =) So, one step closer! But I still can't see symbols for calls into my AOT'd library in Instruments... =(

  • RogisterAlainRogisterAlain BEBeta ✭✭✭

    Hi Chris,

    I tried to compile my project with the --aot=all option and no problems at compilation.

    I'm in framework mobile.xamarin.mac

    Can I use this in production and is it really more efficient ?

    Thanks

    Alain

  • ChrisHamonsChrisHamons USXamarin Team Xamurai

    So you can read about AOT here (https://medium.com/@donblas/ahead-of-time-compilation-with-xamarin-mac-ceb6fb1d0a3c), though it was more experimental when I wrote it, but the short answer is that there are two areas where AOT help:

    • Better "native" crash logs. If your application crashes in native code, which is common occurrence when you look at Cocoa the wrong way, native crash logs with JIT frames are difficult to analyze. Since the JIT frames do not have debug information, you'll see multiple lines with hex offsets and no clue what was going on. AOT generates "real" named frames and the traces are much easier to read. This also means we interact better with native tools such as lldb and Instruments.

    • Better launch time performance. If you have a "large" application, with a multiple second startup time, JITing all of your code can take a significant amount of time. AOT does this work up front.

    What it won't do is improve "general" program performance" Most applications are not bound by JIT time during use and won't see much change after launch.

  • ChrisHamonsChrisHamons USXamarin Team Xamurai

    Oh, and to answer your question on "is it safe". The best answer I can give you is "likely". The AOT code generator in mono is battle tested and I have seen Xamarin.Mac integration with AOT specific bugs.

    However, the feature only had moderate QA testing and few users tested it in the field so far. This is why the documentation still marks it as "experimental".

    I know of no reason why you shouldn't ship with it enabled if things work, but that's the background.

  • RogisterAlainRogisterAlain BEBeta ✭✭✭

    Thank you for the answer.

    Can you tell me if the problem of -register = dynamic is solved because when I posted my application to apple, it was refused because I was using a library that was not even in my project.

    I had to reset -register = static to move the application to the AppStore.

  • ChrisHamonsChrisHamons USXamarin Team Xamurai

    @RogisterAlain We're becoming increasingly off topic (and should start another thread) but no - if you use XM Full (4.5) target framework and are submitting to the app store, you have to use --registrar=dynamic for now.

    I wrote more details here:

    https://medium.com/@donblas/how-a-default-behavior-change-broke-mac-app-store-submissions-bb92314065a0

  • RogisterAlainRogisterAlain BEBeta ✭✭✭

    sorry but thanks for the answer

  • RogisterAlainRogisterAlain BEBeta ✭✭✭

    Hi Chris,

    I come back to you for the AOT compilation.

    For several months now, my application crash randomly to different places, not often in the same place, for no apparent reason and the log report does not know the real problem. So it's really annoying.

    I tried the AOT compilation by putting as parameter: --aot = all

    I compile and there, MIRACLE, my application no longer crashes at all. I can work with for hours.

    Do you have an explanation for that ? Is this a bug with Xamarin's JIT ?

    Thanks

    Alain

  • ChrisHamonsChrisHamons USXamarin Team Xamurai

    I can think of a number of explanations, but without data, they are only wild guesses. In order of likelihood:

    • There is one or more race conditions in your code, which have their timing changed just enough by AOT to make them disappear.
    • You have some bug in native code (your own or a library you are calling) that is scribbling over memory, but AOT is more resistant to.
    • There is one or more timing related conditionals in your code, say responding to networking, which have their timing changed enough to make the issue disappear.
    • You have some native code somewhere that is attempting to walk the stack of running threads that is getting confused by mono's frames, but AOTed frames look similar enough to native ones that it does not have trouble and randomly corrupt things.
    • There is an actual JIT bug not in AOT. This seems rather unlikely, but stranger things have happened.

    If you track down more information, with a small reproducible sample, please file a bug at bugzilla.xamarin.com

  • RogisterAlainRogisterAlain BEBeta ✭✭✭

    thank you for the answer

    I still think the crash problems I encounter are problems with "bad" memory management.

    An example: I have a toolbar with a button and when I click on it, I change the content of the view. It works all the time and sometimes, when I click on the button, it crashes. Sometimes I can do it dozens of times and no problem. Sometimes, after 2 clicks, it crashes.

    This is an example but often when I click a button that opens a new window or changes the view in a single window.

    This is impossible to reproduce with a small application. I think as you say it is due to the code that is specific to this window.

    It is true that in this application, there are many network calls (webservice), a lot of timer management, maybe it comes from there. I do not know.

2»
Sign In or Register to comment.