Static registrar with NativeAOT design – discussion

[ivanpovazan]

Description

Microsoft.macOS and Microsoft.iOS enable Objective-C runtime to create instances of C# classes through a type registration system. The type registration can be static – used for device builds and dynamic – used for emulators. At build time, the static registration inspects the assemblies used by the application through a custom linker step. It determines the classes and methods to register with Objective-C and generates a map, which is embedded into the binary. At the application startup, the map is registered with the Objective-C runtime (source).

However, to resolve addresses of registered types, type (and module) metadata tokens are used, which are not available in NativeAOT representations of managed types. This limitation prevents using NativeAOT for applications built on top of Microsoft.macOS and Microsoft.iOS.

This issue has been opened for discussion, possible approaches, ideas and suggestions on how to get pass this limitation with a goal of enabling NativeAOT to work with Xamarin.

/cc: @rolfbjarne

---

PS I would also like to give credit to @AustinWise who also reported this limitation in: #77472

Tagging subscribers to 'os-ios': @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Microsoft.macOS and Microsoft.iOS enable Objective-C runtime to create instances of C# classes through a type registration system. The type registration can be static – used for device builds and dynamic – used for emulators. At build time, the static registration inspects the assemblies used by the application through a custom linker step. It determines the classes and methods to register with Objective-C and generates a map, which is embedded into the binary. At the application startup, the map is registered with the Objective-C runtime (source).

However, to resolve addresses of registered types, type (and module) metadata tokens are used, which are not available in NativeAOT representations of managed types. This limitation prevents using NativeAOT for applications built on top of Microsoft.macOS and Microsoft.iOS.

This issue has been opened for discussion, possible approaches, ideas and suggestions on how to get pass this limitation with a goal of enabling NativeAOT to work with Xamarin.

/cc: @rolfbjarne

---

PS I would also like to give credit to @AustinWise who reported this limitation in: #77472

Author:	ivanpovazan
Assignees:	-
Labels:	design-discussion, os-ios, area-NativeAOT-coreclr
Milestone:	8.0.0

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Microsoft.macOS and Microsoft.iOS enable Objective-C runtime to create instances of C# classes through a type registration system. The type registration can be static – used for device builds and dynamic – used for emulators. At build time, the static registration inspects the assemblies used by the application through a custom linker step. It determines the classes and methods to register with Objective-C and generates a map, which is embedded into the binary. At the application startup, the map is registered with the Objective-C runtime (source).

However, to resolve addresses of registered types, type (and module) metadata tokens are used, which are not available in NativeAOT representations of managed types. This limitation prevents using NativeAOT for applications built on top of Microsoft.macOS and Microsoft.iOS.

This issue has been opened for discussion, possible approaches, ideas and suggestions on how to get pass this limitation with a goal of enabling NativeAOT to work with Xamarin.

/cc: @rolfbjarne

---

PS I would also like to give credit to @AustinWise who reported this limitation in: #77472

Author:	ivanpovazan
Assignees:	-
Labels:	design-discussion, os-ios, area-NativeAOT-coreclr
Milestone:	8.0.0

[ivanpovazan]

After some internal discussions with @rolfbjarne and @MichalStrehovsky one idea to tackle this limitation that came up, was to expose all managed methods with UnmanagedCallersOnly attribute and change the Objective-C code to invoke managed methods symbolically. However, this approach also raises other questions e.g., how to handle non-blittable parameter types, etc.

[jkotas]

Resolving tokens or looking up a lot of types or methods by name during startup is wasted time. It would be best to auto-generate C# code with embedded fully resolved references to the types and methods, and compile this code into the app.

However, this approach also raises other questions e.g., how to handle non-blittable parameter types, etc.

How are non-blittable parameters handled today?

[filipnavara]

How are non-blittable parameters handled today?

Simplified version:

A custom linker step generates the Objective-C version of the object. For every member a code is generated here. That contains part of the marshalling. The generated code calls mono_runtime_invoke which in turn calls xamarin_bridge_runtime_invoke_method and eventually bridges to this managed code which does the rest of the marshalling on the managed side. It has pretty high overhead for simple methods (eg. returning int/bool and taking no parameters) so it would be nice to improve at least that part of the design.

[rolfbjarne]

Resolving tokens or looking up a lot of types or methods by name during startup is wasted time.

I agree (this is one of the big reasons the static registrar exists in the first place).

It would be best to auto-generate C# code with embedded fully resolved references to the types and methods, and compile this code into the app.

I will try to look into this. There are however a few points:

• Some care will have to be taken to not bloat the app. One example I saw many years ago was an app with many generated classes and properties, and the static registrar had to generate code for 15.000+ properties. The total generated code can become quite big if each property is bigger than it needs to be.
• Interaction with the trimmer. Right now we run the static registrar after the trimmer has done its job (and after removing all the API it trimmed). Generating managed code in the static registrar means we'll have to run the static registrar a bit earlier (after marking API, but before removing non-marked API), because we might need some of the API in the generated code (iow the static registrar might have to tell the trimmer to keep API it would otherwise remove). This also influences the trimming design: as I understand it, the NativeAOT compiler does its own trimming (which was partially disabled for the initial proof-of-concept, and we stilled executed ILLinker), and one idea floating around was to figure out how to only use NativeAOT's trimming. I believe using NativeAOT's trimming if the static registrar generates managed code will be a harder problem to solve, because the static registrar needs the trimmed output (it's really unnecessary to generate code for API the trimmer will remove), while at the same time generating new managed code.

[jkotas]

NativeAOT compiler does its own trimming (which was partially disabled for the initial proof-of-concept, and we stilled executed ILLinker), and one idea floating around was to figure out how to only use NativeAOT's trimming.

Can we run the trimmer in analysis-only mode where it only figures out the roots for the static registrar to use without actually rewriting the outputs?

[rolfbjarne]

NativeAOT compiler does its own trimming (which was partially disabled for the initial proof-of-concept, and we stilled executed ILLinker), and one idea floating around was to figure out how to only use NativeAOT's trimming.

Can we run the trimmer in analysis-only mode where it only figures out the roots for the static registrar to use without actually rewriting the outputs?

I guess we could do that, or alternatively have the trimmer write its output, and then use it as input to the static registrar, but pass the original non-trimmed assemblies to the NativeAOT compiler.