TypeMap API: For trimmed and nativeaot builds, provide a list of the types kept by the typemap

[jtschuster]

In Android (and maybe iOS), it is necessary to create Java wrapper types and native glue stubs that call into .NET. It's not necessary to keep these java types and native methods for .NET types that are trimmed away, but there's not an easy way to tell what is necessary for the app. If the TypeMap output the target types in the typemap that are kept, it would greatly simplify and speed up the build process, and create smaller applications.
Alternatively, the android build could inspect every single assembly in trimmed apps, and parse the ILC trimming xml logger for nativeaot apps.

Open questions:

Android works around one Java class mapping to multiple .NET types with a "mapper class" in the TypeMap that points to each of the aliases. This would require additional bookkeeping in the build to remember which types are mapper classes and which java classes and stubs they should keep for those mapper types.

cc. @simonrozsival @AaronRobinsonMSFT

[AaronRobinsonMSFT]

If the TypeMap output the target types in the typemap that are kept

@jtschuster This isn't unreasonable as a build artifact from the tooling. I would expect this to be next to the assembly in the final output directory. I'd like to hear from @agocke and @MichalStrehovsky as well regarding the format/semantics.

[agocke]

If the TypeMap output the target types in the typemap that are kept, it would greatly simplify and speed up the build process, and create smaller applications.

How much of an improvement are we talking about? That would set a good ballpark for the benefit.

cc @sbomer

[simonrozsival]

I don't have the exact number at the moment, but we are talking about several hundreds of java classes + corresponding native code which would be packed in the app and not used.

I believe this is not a blocking issue for PoC. Once we have a PoC, we will have exact numbers and we can evaluate, if this is worth the effort and added complexity.

[rolfbjarne]

This will be necessary for iOS, for a few of reasons:

1. The native linker will trim dead code, which means that if a managed project references a third-party binding project, but doesn't actually use all of the native code from that binding project, then the native linker will remove that unused native code. This can have a snowballing effect on trimmed apps; which we wouldn't be taking advantage of because we'd keep a strong reference to all native types declared in that third-party binding project.
2. We depend on the trimmer to trim away code that would otherwise trigger additional App Store requirements. For instance, using the HealthKit API requires an entitlement to do so, and when an app is uploaded to the App Store, the App Store will validate that the app has the HealthKit entitlement if the app links with the HealthKit framework. This means that we can't link in any native code that references the HealthKit framework (unless the app actually wants to use the HealthKit framework); and the typemap will contain types from the HealthKit framework.

[agocke]

Cc @jkoritzinsky

[agocke]

@rolfbjarne are you only referring to il trimming here? Native aot should also remove all unreachable pinvokes, so I don’t see how an additional list is necessary or useful

[rolfbjarne]

@rolfbjarne are you only referring to il trimming here? Native aot should also remove all unreachable pinvokes, so I don’t see how an additional list is necessary or useful

Before trimming (either by ILLink or NativeAOT) we'll generate supporting native code for a number of C# classes.

The question is how to not include native code for C# classes that were trimmed away in the app, when we don't necessarily know which C# classes were trimmed away (NativeAOT).

It might be possible to use DirectPInvoke for all P/Invokes, link with all the supporting native code, and then just have the native linker remove any supporting native code that's not referenced. This will only work if NativeAOT doesn't root every DirectPInvoke though. It'll also only work if the app doesn't depend on any custom native library loading behavior, and doesn't have P/Invokes to methods that don't exist.

There's also the fact that this process is wasteful: we'll generate native code (and compile it, and link with it) for a number of C# classes that will be trimmed away, solely because we don't know which C# classes survives trimming. Ideally we'll only be generating native code for C# classes that survives trimming.

[agocke]

Also @MichalStrehovsky