MonoTouch AOT编译器 - 大型方法失败

时间:2012-05-15 15:27:18

标签: c# .net xamarin.ios aot monogame

我正在开发游戏,我们一直在以JSON格式存储我们的关卡信息。这些级别非常大,所以我们切换到只将它们存储在普通的C#:

  • 顶级方法有一个用于级别/对象名称的switch语句
  • 有几种自动生成的方法使用标准属性inititalizers“新建”我们的对象树

示例:

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

除了这些方法非常大并且具有其他对象的嵌套列表/字典等

这加快了将级别从2-3秒加载到几分之一秒的时间(在Windows上)。我们的数据大小也相当小,因为已编译的IL与JSON相比。

问题是当我们在MonoDevelop中为MonoTouch编译这些时,我们得到:

mtouch exited with code 1

启用-v -v -v后,我们可以看到错误:

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

编译AOT时,方法中的行数是否有限制?我们可以通过mtouch来解决这个问题吗?有些文件工作正常,但特别是导致错误的文件有3000行方法。无论如何编译模拟器都能正常工作。

这仍然是一个实验,所以我们意识到这是一个相当疯狂的情况。

2 个答案:

答案 0 :(得分:4)

当您遇到AOT编译器中从不发生的情况时,会发生这些断言。请将此类案例报告给http://bugzilla.xamarin.com

  

我们可以通过mtouch来解决这个问题吗?

可能能够通过使用LLVM(或不使用它)解决此问题,因为它是一个不同的代码生成引擎。根据发生的阶段(有些是共享的),您可能不会遇到相同的情况。

当然,LLVM构建速度较慢,不支持调试,因此对于每种情况而言,这都不是理想的解决方法。

答案 1 :(得分:1)

只是存储水平的建议。您是否考虑过以非常快的二进制格式存储级别,如协议缓冲区? .NET有一个很棒的协议缓冲库,名为Protobuf-net,你可能想要查看它。