MonoTouch AOT Compiler - large methods fail

Question

I'm working on a game, and we have been storing our level information in JSON format. These levels are quite large, so we switched to just storing them in plain C#:

• A top level method has a switch statement for the name of the level/object
• There are several auto-generated methods that "new up" our object tree with standard property inititalizers

Example:

private OurObject Autogenerated_Object1()
{
   return new OurObject { Name = "Object1", X = 1, Y = 2, Width = 200, Height = 100 };
}

Except these methods are very large and have nested lists/dictionaries of other objects, etc.

This has sped up the time of loading a level from 2-3 seconds to fractions of a second (on Windows). The size of our data is also considerable smaller, as compiled IL compared to JSON.

The problem is when we compile these in MonoDevelop for MonoTouch, we get:

mtouch exited with code 1

With -v -v -v turned on, we can see the error:

MONO_PATH=/Users/jonathanpeppers/Desktop/DrawAStickman/Game/Code/iOS/DrawAStickman.iPhone/bin/iPhone/Release/DrawAStickmaniPhone.app /Developer/MonoTouch/usr/bin/arm-darwin-mono --aot=mtriple=armv7-darwin,full,static,asmonly,nodebug,outfile=/var/folders/4s/lcvdj54x0g72nrsw9vzq6nm80000gn/T/tmp54777849.tmp/monotouch.dll.7.s "/Users/jonathanpeppers/Desktop/DrawAStickman/Game/Code/iOS/DrawAStickman.iPhone/bin/iPhone/Release/DrawAStickmaniPhone.app/monotouch.dll"
AOT Compilation exited with code 134, command:
MONO_PATH=/Users/jonathanpeppers/Desktop/DrawAStickman/Game/Code/iOS/DrawAStickman.iPhone/bin/iPhone/Release/DrawAStickmaniPhone.app /Developer/MonoTouch/usr/bin/arm-darwin-mono --aot=mtriple=armv7-darwin,full,static,asmonly,nodebug,outfile=/var/folders/4s/lcvdj54x0g72nrsw9vzq6nm80000gn/T/tmp54777849.tmp/DrawAStickmanCore.dll.7.s "/Users/jonathanpeppers/Desktop/DrawAStickman/Game/Code/iOS/DrawAStickman.iPhone/bin/iPhone/Release/DrawAStickmaniPhone.app/DrawAStickmanCore.dll"
Mono Ahead of Time compiler - compiling assembly /Users/jonathanpeppers/Desktop/DrawAStickman/Game/Code/iOS/DrawAStickman.iPhone/bin/iPhone/Release/DrawAStickmaniPhone.app/DrawAStickmanCore.dll
* Assertion: should not be reached at ../../../../../mono/mono/mini/mini-arm.c:2758

Is there a limit to the number of lines in a method, when compiling for AOT? Is there some argument we can pass to mtouch to fix this? Some files work fine, but one in particular that causes the error has a 3,000 line method. Compiling for the simulator works fine no matter what.

This is still an experiment, so we realize this is a pretty crazy situation.

Dutiable

Does it work with small levels? – Almeida

Yes, works fine with smaller levels. As soon as I add a particular bush or tree the trouble starts--and simulator works fine. – Dutiable

Answer 1

Those asserts occurs when you hit a condition that should never occur in the AOT compiler. Please report such cases to http://bugzilla.xamarin.com

Is there some argument we can pass to mtouch to fix this?

You might be able to workaround this by using LLVM (or not using it) since it's a different code generation engine. Depending at which stage this occurs (some are shared) you might not run into the same condition.

Of course LLVM builds are slower and does not support debugging so this is not an ideal workaround for every circumstances.

Pedicab

I'll make a sample project and report the bug. I get a similar error compiling with LLVM: * Assertion at ../../../../../mono/mono/mini/ssa.c:243, condition stack_history_len < stack_history_size' not met` – Dutiable

Zoltan says it's fixed, not sure how long until it's in the alpha/beta channel to try out. – Dutiable

It won't be in 5.2.12 since that release process was already under way. The next one should be 5.3.4 (alpha) and should contain it. – Pedicab

Answer 2

Just a recommendation for storage of the levels. Have you considered storing the levels in a very fast binary format like Protocol Buffers? .NET has a wonderful protocol buffers library called Protobuf-net that you might want to check out.

Sandasandakan

I've looked at it, problem is I have nested lists/dictionaries, plus class with multiple lists (jagged arrays) and it doesn't have support for that. – Dutiable

You might be able to wrap the inner arrays/lists as classes and serialize that way. But you've probably already explored that option. – Sandasandakan

MsgPack is another option. I am using it to serialize over the network and at some point may use it to replace Json for faster serialization to disk. – Apperception