New hostfxr hosting API design - discussion

[ivanpovazan]

Description

It is needless to say that startup performance is critical for mobile applications. As we are exploring the support of CoreCLR for mobile we have identified several inefficiencies with currently available hosting APIs which need to be addressed in order to achieve best performance possible.

One example of such inefficiency is related to how the runtime properties can be passed to the runtime during initialization.
If we consider CoreCLR's private hosting APIs, like coreclr_initialize, runtime configuration properties' values are accepted as UTF8 strings. Which means that pointers need to be converted to UTF8 strings which are internally converted back to pointers. The conversion pointer-string-pointer seems redundant and negatively impacts the performance during startup. Additionally, this conversion could break tagged pointers on ARMv8+.
On the other hand, the public hosting hostfxr APIs support passing runtime configuration properties as a json file, which is also not ideal.

Going forward, we would like to avoid using private hosting APIs and use hostfxr APIs instead.

The goal of this issue is to open up a discussion between our hosting and iOS/Android/WASM experts in order to collect list of requirements specific to each platform and from that design new highly performant hosting API to successfully support CoreCLR on them.

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

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

[ivanpovazan]

/cc: @AaronRobinsonMSFT @elinor-fung @jkotas @grendello @jonpryor @rolfbjarne @pavelsavara

[rolfbjarne]

Going forward, we would like to avoid using private hosting APIs and use hostfxr APIs instead.

What's wrong with the private hosting APIs?

From https://github.com/dotnet/runtime/blob/main/docs/design/features/native-hosting.md:

hostfxr and hostpolicy APIs [...] These can execute application, determine available SDKs, determine native dependency locations, resolve component dependencies and so on.

That sounds like a massive overkill for what we need it for. We know which SDK to use (it's embedded in the app), we know where all the native dependencies are (also all in the app), etc.

Our startup needs are really rather simple:

1. First we need to call a specific managed method, which will initialize all our managed logic.
2. Optionally call the managed Main method.
   • App extensions don't have a managed Main method, the entry point into managed code can be any API we've exposed to Objective-C.

Note that for NativeAOT we don't neither of those two points, because we expose both our initialization method + the managed Main method using [UnmanagedCallersOnly] entry points we just call from native code.

So I think our needs can be stated rather simply: we can figure out a lot at build time, so we need a hosting API that takes advantage of that fact.

[jkotas]

Which means that pointers need to be converted to UTF8 strings which are internally converted back to pointers.

This assumes that the source of truth for the property values are UTF16 strings. Is it really the case?

In general, file formats and the Unix APIs are UTF8 that makes UTF8/UTF16 conversions very common. A few more should not be a big deal.

BTW: Our C/C++ implementation of UTF8/UTF16 conversions seems to be leaving perf on the table, but it have not showed up on the radar except for this PR micro-benchmark: #102424 (comment)

Additionally, this conversion could break tagged pointers on ARMv8+.

I do not see a problem here.

list of requirements

My list would be:

• Allow efficient zero-copy loading of both IL and native code. The scheme implemented in Allow R2R for images provided via external_assembly_probe #112934 ends up copying all native code. It is inefficient (megabytes of memory copied), and it won't work for platforms that prohibit dynamic code generation.
• No json parsing during startup in fully self-contained Android/iOS/WASM apps. As @rolfbjarne said, we can figure all of this at build time.
• Be lazy as much as possible, avoid materializing very long strings. TRUSTED_PLATFORM_ASSEMBLIES value that is extremely long string is the main offender. Expand host_runtime_contract to get assembly names and resolve their paths #100503 (comment) has done some experiments with fixing it.

[rolfbjarne]

Which means that pointers need to be converted to UTF8 strings which are internally converted back to pointers.

This assumes that the source of truth for the property values are UTF16 strings. Is it really the case?

No, for some of the properties the source of truth is a pointer - some properties are function pointers.

One example is PINVOKE_OVERRIDE, we do:

char *pinvokeOverride = strdup_printf ("%p", &xamarin_pinvoke_override); // xamarin_pinvoke_override is a C function
coreclr_initialize (..., pinvokeOverride, ...); // very pseudo code here