Are C# Expression Trees (or ILGenerator) allowed on iOS

Hum too bad ^^'
Now I can inject / change code within a DLL with Harmony Patcher , which could potentially allow me to expose a method to force AOT to realise use cases, just like this AotHelper for Newtonsoft Json.

Code (CSharp):

1.  
2. public class DeleguateIssue : MonoBehaviour
3. {
4.     delegate void Call(int param);
5.     Call _calledThroughEfficientReflection;
6.     void OptimizedDelegate(int test) => Debug.Log("Successfully called with "+test);
7.     void Awake()
8.     {
9.         try
10.         {
11.             var methodInfo = GetType().GetMethod("OptimizedDelegate", BindingFlags.Instance | BindingFlags.NonPublic);
12.             var param = Expression.Parameter(typeof(int));
13.             var callParent = Expression.Call(Expression.Constant(this), methodInfo, param);
14.             _calledThroughEfficientReflection = Expression.Lambda<Call>(callParent, param).Compile();
15.             _calledThroughEfficientReflection(5);
16.         }
17.         catch (Exception e)
18.         {
19.             Debug.LogException(e);
20.         }
21.     }
22. }
23.  

It's interesting to see that Expression.Lambda.Compile works,
However calling the delegate create the following bug at runtime:

Code (CSharp):

1. ExecutionEngineException: Attempting to call method 'System.Linq.Expressions.Interpreter.LightLambda::RunVoid1<System.Int32>' for which no ahead of time (AOT) code was generated.
2.   at UnityEngine.AudioClip+PCMSetPositionCallback.Invoke (System.Int32 position) [0x00000] in <00000000000000000000000000000000>:0
3.   at DefaultNamespace.DeleguateIssue.Start () [0x00000] in <00000000000000000000000000000000>:0
4.  

But I can't find this System.Linq.Expressions.Interpreter.LightLambda or even its namespace in any of the DLL we have. I'm quite confused, but I'm guessing "System.Linq.Expressions.Interpreter" is generated during compilation ?
If I could understand how/when this is created, maybe I could inject myself somewhere I could help/force AOT compilation.

Edit: I just realized how wrong/weird is the stack trace ? Why is there UnityEngine.AudioClip+PCMSetPositionCallback.Invoke there

 

I created a bug report 1216861.
I could see that LightLambda seems to be from System.Core online, however exploring my System.Core.dll with DotNet Peek, I could not see the Interpreter namespace :

Spoiler: Screenshot

Edit: It's also missing from there : https://referencesource.microsoft.com/#System.Core,namespaces

 

We finally found it in "Editor\Data\MonoBleedingEdge\lib\mono\unityaot\System.Core.dll". My dotnet peek search must not be working properly ¯\_(ツ)_/¯.
I'm now studying how I can patch the dll to expose a method that would help the compiler generate AOT code for the types we use.

 

We're looking into using expression trees to set fields on a large number of components - but it looks like there is a large performance cost with IL2Cpp:
https://answers.unity.com/storage/temp/159653-il2cppperformance.png (not my image, from https://answers.unity.com/questions/1731418/il2cpp-compiled-expressions-performance.html)

Is this because it's just using Reflection internally, so there is no advantage to using a expression tree like this rather than a FieldInfo.SetValue()? Doesnt look like there is a way around this

 

Pardon me to digging up this old thread but is this limitation was resolved by any means? Can we use `System.Linq.Expressions` with value type in newer version of unity IL2CPP yet?

 

Thank you very much

 

This is great news! You have my thanks too!

 

Worth saying that Apple changed thier TOS some time ago:

 

That's pretty nice.
Makes me wish that endeavours like MoonSharp or other runtime scripting tools were still maintained.

 

Could you check if these improvements have already reached the 2021.2 beta? because I've just tried building with "Faster (smaller) builds" option enabled, but I couldn't see any performance improvements on getter/setter compiled expressions. I've built with 2021.2.0b8.3289.

 

If it's decided that the improved compilation time isn't worth it (maybe say due to decreased runtime performance) could we please still have the interpreter as a fallback in IL2CPP? It would allow stuff which was previously impossible with as far as I am aware no downsides (other than the code size cost of the interpreter). This would be amazing

 

@JoshPeterson As of late there was changed in apple policy to allow JIT support in ios

https://twitter.com/altstoreio/status/1413180831636492288

Does unity have a plan to enable full JIT support for dynamic and Reflection.Emit and various feature in ios?

 

Only interpreted code works everywhere and is allowed in Apple Developer Program License Agreement 3.3.2 https://developer.apple.com/support...rogram-License-Agreement-20210607-English.pdf

 

It doesn't required to be downloaded or installed. At the very least is allow dynamic type which is not change primary purpose of everything. It also enabled a feature in game that allow user to write a code to control the game, or direct modding of the program without losing performance (this is not downloaded or installed and if it was the intended purpose of the game it should also allowed too, it even declare permission in the next paragraph)

The `interpreted code` mention there I think it not meant to limit only interprete mechanism. I think it include JIT and any scripting system. And we could just avoid making store or storefront

 

Splendid! So is this something that will need to be enabled by the user in some way or will all IL2CPP builds on 2022.1+ support dynamically created value type generics? (due to the new interpreter)

 

Thank you for your response. Are there any consideration about mono on ios? Or dotnet 6 on ios and android?

 

@JoshPeterson Imagine I'm building to Android (IL2CPP), it is possible somehow to have those expressions compiled on a PostBuild processor? Something like Mono.Cecil, but with expressions instead? If yes, do you have any sample or guidance? Thanks in advance

 

That's unfortunate. Looking at trends more and more games allow players to be creators (roblox best example). There are many Unity games that refuse to add scripting as it's not cross platform (won't work in il2cpp ios). Hopefully that will change at some point. This should have a bit higher priority. As you can imagine players that end up learning and scripting in C# in a game would have pretty easy way of picking up Unity. In a sense it's a way of converting players to Unity users.

Worth saying that Unreal noticed it and they're adding new language for that exact purpose https://twitter.com/Nephasto/status/1340046706642186247/


Another take on this feature is new Battlefield Portal with visual scripting:


Maybe that's something that could be done as there's even "High performance interpreter" on visual scripting roadmap https://unity.com/roadmap/unity-platform/gameplay-ui-design

 

.NET has an interpreter fallback to make ExpressionTree work in NativeAOT scenario: https://github.com/dotnet/runtime/t...sions/src/System/Linq/Expressions/Interpreter
And they use predefined constants (FEATURE_COMPILE and FEATURE_INTERPRET) to determine whether to enable it or not: https://github.com/dotnet/runtime/b...tem/Linq/Expressions/LambdaExpression.cs#L147

You may want to see how they defined those constants for building NativeAOT runtime: https://github.com/dotnet/runtimelab/tree/feature/NativeAOT

 

Are there any progress about this feature?

 

Thank you so much for your all hard work

 

@JoshPeterson If they don't select this option, can we still exist the full generic sharing to be present and hence fix these reflection like issues we're having? Does that option enable generic sharing or does it force generic sharing over dedicated compilation? Thanks!

 

So... does that mean expression trees now work in all IL2CPP platforms? (if not, can you expand on constraints, please?)

 

How it works in 2022.1 sounds perfect, and I understand why it didn't work like that in 2021 (wanted to get it out earlier in some form until it was ready)
Thanks for staying on top of this over all these years! Very exciting