[mono] Add conditional substitution for IsDynamicCodeSupported when targeting ios-like platforms

[ivanpovazan]

This PR introduces conditional linker substitution for get_IsDynamicCodeSupported method when targeting ios-like platforms with mono.
The substitution is enabled when feature switch DynamicCodeSupport is set to false, which should only happen in fullAOT mode - with no interpreter fallback.

Contributes to: dotnet/macios#18340

[ghost]

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

Issue Details

---

This PR introduces conditional linker substitution for get_IsDynamicCodeSupported method when targeting ios-like platforms with mono.
The substitution is enabled when feature switch DynamicCodeSupport is set to false, which should only happen in fullAOT mode - with no interpreter fallback.

Contributes to: dotnet/macios#18340

Author:	ivanpovazan
Assignees:	ivanpovazan
Labels:	os-ios, needs-area-label
Milestone:	-

[ivanpovazan]

/azp run runtime-ioslike

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27
not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

[steveisok]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27 not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

I think once Alex can land a fix for dotnet/sdk#25392, we would have the option of having it set in the SDK. There will likely need to be properties for nativeaot and monoaot.

[lewing]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27 not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

I think once Alex can land a fix for dotnet/sdk#25392, we would have the option of having it set in the SDK. There will likely need to be properties for nativeaot and monoaot.

You can set it in WorkloadManifest.targets now

[lewing]

The linker substitution doesn't look conditional to me?

[ivanpovazan]

@lewing thanks for your input, I have a couple of questions:

You can set it in WorkloadManifest.targets now

• Is this the right place? https://github.com/dotnet/runtime/blob/84a7be769fa9054dac7a973dda538cf61a488e56/src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Current.Manifest/WorkloadManifest.targets.in

• Are WorkloadManifest.targets imported in xamarin/maui projects?

The linker substitution doesn't look conditional to me?

• feature="System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported" featurevalue="false" makes it conditional in the sense that the method get_IsDynamicCodeSupported() will be replaced with false by the trimmer if the DynamicCodeSupport feature switch is set to false. Otherwise, there will be no substitution.

[marek-safar]

This needs to be wired up into some internal msbuild property otherwise it has no effect because we don't want anyone to change this manually.

[ivanpovazan]

This needs to be wired up into some internal msbuild property otherwise it has no effect because we don't want anyone to change this manually.

Agreed.
I propose as a mid-term solution to set DynamicCodeSupport around here: https://github.com/xamarin/xamarin-macios/blob/cc35efe4bc46f2aa32a0190356cedaad2723e266/dotnet/targets/Xamarin.Shared.Sdk.targets#L118-L122 once this PR lands.
As a long-term solution, it will be set in the SDK once the work dotnet/sdk#25392 is completed.

Do you agree @marek-safar ?

[ivanpovazan]

/cc: @lambdageek

[ivanpovazan]

/azp run runtime-ioslike

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

Failures seem unrelated

[ivanpovazan]

I have removed the previously added test as this set up is not unit testable for which I have considered:

1. Using reflection to test whether a code path guarded by RuntimeFeature.IsDynamicCodeSupported is preserved; but in that case ILLink will preserve dependencies that are referenced dynamically (through reflection) defeating the purpose of the test
2. Manually setting AppContext.SetSwitch("System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported", true); and making sure it does not have any effect. However, in that case MonoAOT actually does not look into managed side (and the AppContext) when determining the value for RuntimeFeature.IsDynamicCodeSupported, instead it performs an instrinsic optimisation:

   runtime/src/mono/mono/mini/intrinsics.c

   Lines 2116 to 2133 in ed26344

   	// On FullAOT, return false for RuntimeFeature:
   	// - IsDynamicCodeCompiled
   	// - IsDynamicCodeSupported and no interpreter
   	// otherwise use the C# code in System.Private.CoreLib
   	if (in_corlib&&
   	cfg->full_aot&&
   	!strcmp ("System.Runtime.CompilerServices", cmethod_klass_name_space) &&
   	!strcmp ("RuntimeFeature", cmethod_klass_name)) {
   	if (!strcmp (cmethod->name, "get_IsDynamicCodeCompiled")) {
   	EMIT_NEW_ICONST (cfg, ins, 0);
   	ins->type=STACK_I4;
   	returnins;
   	} elseif (!strcmp (cmethod->name, "get_IsDynamicCodeSupported") && !cfg->interp) {
   	EMIT_NEW_ICONST (cfg, ins, 0);
   	ins->type=STACK_I4;
   	returnins;
   	}
   	}

None of the approaches seems feasible.

---

Finally, as this change only affects app size, the verification and impact should be observable in size/perf measurements.
This will also open opportunities for further size optimisations like:

• [WIP] System.Linq.Expressions.Interpreter.CallInstruction.CanCreateArbitraryDelegates should respect IsDynamicCodeSupported #86758
• LambdaExpression.CanCompileToIL should respect IsDynamicCodeSupported #80759

[eerhardt]

LGTM. I agree testing this change here is not really feasible at this time. Maybe if we had "dotnet-linker-tests" for iOS working, it could be possible.

[ivanpovazan]

This PR introduces conditional linker substitution for get_IsDynamicCodeSupported method when targeting ios-like platforms with mono.
The substitution is enabled when feature switch DynamicCodeSupport is set to false, which should only happen in fullAOT mode - with no interpreter fallback.

Contributes to: dotnet/macios#18340

[ghost]

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

Issue Details

---

This PR introduces conditional linker substitution for get_IsDynamicCodeSupported method when targeting ios-like platforms with mono.
The substitution is enabled when feature switch DynamicCodeSupport is set to false, which should only happen in fullAOT mode - with no interpreter fallback.

Contributes to: dotnet/macios#18340

Author:	ivanpovazan
Assignees:	ivanpovazan
Labels:	os-ios, needs-area-label
Milestone:	-

[ivanpovazan]

/azp run runtime-ioslike

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27
not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

[steveisok]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27 not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

I think once Alex can land a fix for dotnet/sdk#25392, we would have the option of having it set in the SDK. There will likely need to be properties for nativeaot and monoaot.

[lewing]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27 not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

I think once Alex can land a fix for dotnet/sdk#25392, we would have the option of having it set in the SDK. There will likely need to be properties for nativeaot and monoaot.

You can set it in WorkloadManifest.targets now

[lewing]

The linker substitution doesn't look conditional to me?

[ivanpovazan]

@lewing thanks for your input, I have a couple of questions:

You can set it in WorkloadManifest.targets now

• Is this the right place? https://github.com/dotnet/runtime/blob/84a7be769fa9054dac7a973dda538cf61a488e56/src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Current.Manifest/WorkloadManifest.targets.in

• Are WorkloadManifest.targets imported in xamarin/maui projects?

The linker substitution doesn't look conditional to me?

• feature="System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported" featurevalue="false" makes it conditional in the sense that the method get_IsDynamicCodeSupported() will be replaced with false by the trimmer if the DynamicCodeSupport feature switch is set to false. Otherwise, there will be no substitution.

[marek-safar]

This needs to be wired up into some internal msbuild property otherwise it has no effect because we don't want anyone to change this manually.

[ivanpovazan]

This needs to be wired up into some internal msbuild property otherwise it has no effect because we don't want anyone to change this manually.

Agreed.
I propose as a mid-term solution to set DynamicCodeSupport around here: https://github.com/xamarin/xamarin-macios/blob/cc35efe4bc46f2aa32a0190356cedaad2723e266/dotnet/targets/Xamarin.Shared.Sdk.targets#L118-L122 once this PR lands.
As a long-term solution, it will be set in the SDK once the work dotnet/sdk#25392 is completed.

Do you agree @marek-safar ?

[ivanpovazan]

/cc: @lambdageek

[ivanpovazan]

/azp run runtime-ioslike

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

Failures seem unrelated

[ivanpovazan]

I have removed the previously added test as this set up is not unit testable for which I have considered:

1. Using reflection to test whether a code path guarded by RuntimeFeature.IsDynamicCodeSupported is preserved; but in that case ILLink will preserve dependencies that are referenced dynamically (through reflection) defeating the purpose of the test
2. Manually setting AppContext.SetSwitch("System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported", true); and making sure it does not have any effect. However, in that case MonoAOT actually does not look into managed side (and the AppContext) when determining the value for RuntimeFeature.IsDynamicCodeSupported, instead it performs an instrinsic optimisation:

   runtime/src/mono/mono/mini/intrinsics.c

   Lines 2116 to 2133 in ed26344

   	// On FullAOT, return false for RuntimeFeature:
   	// - IsDynamicCodeCompiled
   	// - IsDynamicCodeSupported and no interpreter
   	// otherwise use the C# code in System.Private.CoreLib
   	if (in_corlib&&
   	cfg->full_aot&&
   	!strcmp ("System.Runtime.CompilerServices", cmethod_klass_name_space) &&
   	!strcmp ("RuntimeFeature", cmethod_klass_name)) {
   	if (!strcmp (cmethod->name, "get_IsDynamicCodeCompiled")) {
   	EMIT_NEW_ICONST (cfg, ins, 0);
   	ins->type=STACK_I4;
   	returnins;
   	} elseif (!strcmp (cmethod->name, "get_IsDynamicCodeSupported") && !cfg->interp) {
   	EMIT_NEW_ICONST (cfg, ins, 0);
   	ins->type=STACK_I4;
   	returnins;
   	}
   	}

None of the approaches seems feasible.

---

Finally, as this change only affects app size, the verification and impact should be observable in size/perf measurements.
This will also open opportunities for further size optimisations like:

• [WIP] System.Linq.Expressions.Interpreter.CallInstruction.CanCreateArbitraryDelegates should respect IsDynamicCodeSupported #86758
• LambdaExpression.CanCompileToIL should respect IsDynamicCodeSupported #80759

[eerhardt]

LGTM. I agree testing this change here is not really feasible at this time. Maybe if we had "dotnet-linker-tests" for iOS working, it could be possible.

[ivanpovazan]

This PR introduces conditional linker substitution for get_IsDynamicCodeSupported method when targeting ios-like platforms with mono.
The substitution is enabled when feature switch DynamicCodeSupport is set to false, which should only happen in fullAOT mode - with no interpreter fallback.

Contributes to: dotnet/macios#18340

[ghost]

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

Issue Details

---

This PR introduces conditional linker substitution for get_IsDynamicCodeSupported method when targeting ios-like platforms with mono.
The substitution is enabled when feature switch DynamicCodeSupport is set to false, which should only happen in fullAOT mode - with no interpreter fallback.

Contributes to: dotnet/macios#18340

Author:	ivanpovazan
Assignees:	ivanpovazan
Labels:	os-ios, needs-area-label
Milestone:	-

[ivanpovazan]

/azp run runtime-ioslike

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27
not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

[steveisok]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27 not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

I think once Alex can land a fix for dotnet/sdk#25392, we would have the option of having it set in the SDK. There will likely need to be properties for nativeaot and monoaot.

[lewing]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27 not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

I think once Alex can land a fix for dotnet/sdk#25392, we would have the option of having it set in the SDK. There will likely need to be properties for nativeaot and monoaot.

You can set it in WorkloadManifest.targets now

[lewing]

The linker substitution doesn't look conditional to me?

[ivanpovazan]

@lewing thanks for your input, I have a couple of questions:

You can set it in WorkloadManifest.targets now

• Is this the right place? https://github.com/dotnet/runtime/blob/84a7be769fa9054dac7a973dda538cf61a488e56/src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Current.Manifest/WorkloadManifest.targets.in

• Are WorkloadManifest.targets imported in xamarin/maui projects?

The linker substitution doesn't look conditional to me?

• feature="System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported" featurevalue="false" makes it conditional in the sense that the method get_IsDynamicCodeSupported() will be replaced with false by the trimmer if the DynamicCodeSupport feature switch is set to false. Otherwise, there will be no substitution.

[marek-safar]

This needs to be wired up into some internal msbuild property otherwise it has no effect because we don't want anyone to change this manually.

[ivanpovazan]

This needs to be wired up into some internal msbuild property otherwise it has no effect because we don't want anyone to change this manually.

Agreed.
I propose as a mid-term solution to set DynamicCodeSupport around here: https://github.com/xamarin/xamarin-macios/blob/cc35efe4bc46f2aa32a0190356cedaad2723e266/dotnet/targets/Xamarin.Shared.Sdk.targets#L118-L122 once this PR lands.
As a long-term solution, it will be set in the SDK once the work dotnet/sdk#25392 is completed.

Do you agree @marek-safar ?

[ivanpovazan]

/cc: @lambdageek

[ivanpovazan]

/azp run runtime-ioslike

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

Failures seem unrelated

[ivanpovazan]

I have removed the previously added test as this set up is not unit testable for which I have considered:

1. Using reflection to test whether a code path guarded by RuntimeFeature.IsDynamicCodeSupported is preserved; but in that case ILLink will preserve dependencies that are referenced dynamically (through reflection) defeating the purpose of the test
2. Manually setting AppContext.SetSwitch("System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported", true); and making sure it does not have any effect. However, in that case MonoAOT actually does not look into managed side (and the AppContext) when determining the value for RuntimeFeature.IsDynamicCodeSupported, instead it performs an instrinsic optimisation:

   runtime/src/mono/mono/mini/intrinsics.c

   Lines 2116 to 2133 in ed26344

   	// On FullAOT, return false for RuntimeFeature:
   	// - IsDynamicCodeCompiled
   	// - IsDynamicCodeSupported and no interpreter
   	// otherwise use the C# code in System.Private.CoreLib
   	if (in_corlib&&
   	cfg->full_aot&&
   	!strcmp ("System.Runtime.CompilerServices", cmethod_klass_name_space) &&
   	!strcmp ("RuntimeFeature", cmethod_klass_name)) {
   	if (!strcmp (cmethod->name, "get_IsDynamicCodeCompiled")) {
   	EMIT_NEW_ICONST (cfg, ins, 0);
   	ins->type=STACK_I4;
   	returnins;
   	} elseif (!strcmp (cmethod->name, "get_IsDynamicCodeSupported") && !cfg->interp) {
   	EMIT_NEW_ICONST (cfg, ins, 0);
   	ins->type=STACK_I4;
   	returnins;
   	}
   	}

None of the approaches seems feasible.

---

Finally, as this change only affects app size, the verification and impact should be observable in size/perf measurements.
This will also open opportunities for further size optimisations like:

• [WIP] System.Linq.Expressions.Interpreter.CallInstruction.CanCreateArbitraryDelegates should respect IsDynamicCodeSupported #86758
• LambdaExpression.CanCompileToIL should respect IsDynamicCodeSupported #80759

[eerhardt]

LGTM. I agree testing this change here is not really feasible at this time. Maybe if we had "dotnet-linker-tests" for iOS working, it could be possible.

[ivanpovazan]

This PR introduces conditional linker substitution for get_IsDynamicCodeSupported method when targeting ios-like platforms with mono.
The substitution is enabled when feature switch DynamicCodeSupport is set to false, which should only happen in fullAOT mode - with no interpreter fallback.

Contributes to: dotnet/macios#18340

[ghost]

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

Issue Details

---

This PR introduces conditional linker substitution for get_IsDynamicCodeSupported method when targeting ios-like platforms with mono.
The substitution is enabled when feature switch DynamicCodeSupport is set to false, which should only happen in fullAOT mode - with no interpreter fallback.

Contributes to: dotnet/macios#18340

Author:	ivanpovazan
Assignees:	ivanpovazan
Labels:	os-ios, needs-area-label
Milestone:	-

[ivanpovazan]

/azp run runtime-ioslike

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27
not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

[steveisok]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27 not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

I think once Alex can land a fix for dotnet/sdk#25392, we would have the option of having it set in the SDK. There will likely need to be properties for nativeaot and monoaot.

[lewing]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27 not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

I think once Alex can land a fix for dotnet/sdk#25392, we would have the option of having it set in the SDK. There will likely need to be properties for nativeaot and monoaot.

You can set it in WorkloadManifest.targets now

[lewing]

The linker substitution doesn't look conditional to me?

[ivanpovazan]

@lewing thanks for your input, I have a couple of questions:

You can set it in WorkloadManifest.targets now

• Is this the right place? https://github.com/dotnet/runtime/blob/84a7be769fa9054dac7a973dda538cf61a488e56/src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Current.Manifest/WorkloadManifest.targets.in

• Are WorkloadManifest.targets imported in xamarin/maui projects?

The linker substitution doesn't look conditional to me?

• feature="System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported" featurevalue="false" makes it conditional in the sense that the method get_IsDynamicCodeSupported() will be replaced with false by the trimmer if the DynamicCodeSupport feature switch is set to false. Otherwise, there will be no substitution.

[marek-safar]

This needs to be wired up into some internal msbuild property otherwise it has no effect because we don't want anyone to change this manually.

[ivanpovazan]

This needs to be wired up into some internal msbuild property otherwise it has no effect because we don't want anyone to change this manually.

Agreed.
I propose as a mid-term solution to set DynamicCodeSupport around here: https://github.com/xamarin/xamarin-macios/blob/cc35efe4bc46f2aa32a0190356cedaad2723e266/dotnet/targets/Xamarin.Shared.Sdk.targets#L118-L122 once this PR lands.
As a long-term solution, it will be set in the SDK once the work dotnet/sdk#25392 is completed.

Do you agree @marek-safar ?

[ivanpovazan]

/cc: @lambdageek

[ivanpovazan]

/azp run runtime-ioslike

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

Failures seem unrelated

[ivanpovazan]

I have removed the previously added test as this set up is not unit testable for which I have considered:

1. Using reflection to test whether a code path guarded by RuntimeFeature.IsDynamicCodeSupported is preserved; but in that case ILLink will preserve dependencies that are referenced dynamically (through reflection) defeating the purpose of the test
2. Manually setting AppContext.SetSwitch("System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported", true); and making sure it does not have any effect. However, in that case MonoAOT actually does not look into managed side (and the AppContext) when determining the value for RuntimeFeature.IsDynamicCodeSupported, instead it performs an instrinsic optimisation:

   runtime/src/mono/mono/mini/intrinsics.c

   Lines 2116 to 2133 in ed26344

   	// On FullAOT, return false for RuntimeFeature:
   	// - IsDynamicCodeCompiled
   	// - IsDynamicCodeSupported and no interpreter
   	// otherwise use the C# code in System.Private.CoreLib
   	if (in_corlib&&
   	cfg->full_aot&&
   	!strcmp ("System.Runtime.CompilerServices", cmethod_klass_name_space) &&
   	!strcmp ("RuntimeFeature", cmethod_klass_name)) {
   	if (!strcmp (cmethod->name, "get_IsDynamicCodeCompiled")) {
   	EMIT_NEW_ICONST (cfg, ins, 0);
   	ins->type=STACK_I4;
   	returnins;
   	} elseif (!strcmp (cmethod->name, "get_IsDynamicCodeSupported") && !cfg->interp) {
   	EMIT_NEW_ICONST (cfg, ins, 0);
   	ins->type=STACK_I4;
   	returnins;
   	}
   	}

None of the approaches seems feasible.

---

Finally, as this change only affects app size, the verification and impact should be observable in size/perf measurements.
This will also open opportunities for further size optimisations like:

• [WIP] System.Linq.Expressions.Interpreter.CallInstruction.CanCreateArbitraryDelegates should respect IsDynamicCodeSupported #86758
• LambdaExpression.CanCompileToIL should respect IsDynamicCodeSupported #80759

[eerhardt]

LGTM. I agree testing this change here is not really feasible at this time. Maybe if we had "dotnet-linker-tests" for iOS working, it could be possible.

[ivanpovazan]

This PR introduces conditional linker substitution for get_IsDynamicCodeSupported method when targeting ios-like platforms with mono.
The substitution is enabled when feature switch DynamicCodeSupport is set to false, which should only happen in fullAOT mode - with no interpreter fallback.

Contributes to: dotnet/macios#18340

[ghost]

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

Issue Details

---

This PR introduces conditional linker substitution for get_IsDynamicCodeSupported method when targeting ios-like platforms with mono.
The substitution is enabled when feature switch DynamicCodeSupport is set to false, which should only happen in fullAOT mode - with no interpreter fallback.

Contributes to: dotnet/macios#18340

Author:	ivanpovazan
Assignees:	ivanpovazan
Labels:	os-ios, needs-area-label
Milestone:	-

[ivanpovazan]

/azp run runtime-ioslike

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27
not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

[steveisok]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27 not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

I think once Alex can land a fix for dotnet/sdk#25392, we would have the option of having it set in the SDK. There will likely need to be properties for nativeaot and monoaot.

[lewing]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27 not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

I think once Alex can land a fix for dotnet/sdk#25392, we would have the option of having it set in the SDK. There will likely need to be properties for nativeaot and monoaot.

You can set it in WorkloadManifest.targets now

[lewing]

The linker substitution doesn't look conditional to me?

[ivanpovazan]

@lewing thanks for your input, I have a couple of questions:

You can set it in WorkloadManifest.targets now

• Is this the right place? https://github.com/dotnet/runtime/blob/84a7be769fa9054dac7a973dda538cf61a488e56/src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Current.Manifest/WorkloadManifest.targets.in

• Are WorkloadManifest.targets imported in xamarin/maui projects?

The linker substitution doesn't look conditional to me?

• feature="System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported" featurevalue="false" makes it conditional in the sense that the method get_IsDynamicCodeSupported() will be replaced with false by the trimmer if the DynamicCodeSupport feature switch is set to false. Otherwise, there will be no substitution.

[marek-safar]

This needs to be wired up into some internal msbuild property otherwise it has no effect because we don't want anyone to change this manually.

[ivanpovazan]

This needs to be wired up into some internal msbuild property otherwise it has no effect because we don't want anyone to change this manually.

Agreed.
I propose as a mid-term solution to set DynamicCodeSupport around here: https://github.com/xamarin/xamarin-macios/blob/cc35efe4bc46f2aa32a0190356cedaad2723e266/dotnet/targets/Xamarin.Shared.Sdk.targets#L118-L122 once this PR lands.
As a long-term solution, it will be set in the SDK once the work dotnet/sdk#25392 is completed.

Do you agree @marek-safar ?

[ivanpovazan]

/cc: @lambdageek

[ivanpovazan]

/azp run runtime-ioslike

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

Failures seem unrelated

[ivanpovazan]

I have removed the previously added test as this set up is not unit testable for which I have considered:

1. Using reflection to test whether a code path guarded by RuntimeFeature.IsDynamicCodeSupported is preserved; but in that case ILLink will preserve dependencies that are referenced dynamically (through reflection) defeating the purpose of the test
2. Manually setting AppContext.SetSwitch("System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported", true); and making sure it does not have any effect. However, in that case MonoAOT actually does not look into managed side (and the AppContext) when determining the value for RuntimeFeature.IsDynamicCodeSupported, instead it performs an instrinsic optimisation:

   runtime/src/mono/mono/mini/intrinsics.c

   Lines 2116 to 2133 in ed26344

   	// On FullAOT, return false for RuntimeFeature:
   	// - IsDynamicCodeCompiled
   	// - IsDynamicCodeSupported and no interpreter
   	// otherwise use the C# code in System.Private.CoreLib
   	if (in_corlib&&
   	cfg->full_aot&&
   	!strcmp ("System.Runtime.CompilerServices", cmethod_klass_name_space) &&
   	!strcmp ("RuntimeFeature", cmethod_klass_name)) {
   	if (!strcmp (cmethod->name, "get_IsDynamicCodeCompiled")) {
   	EMIT_NEW_ICONST (cfg, ins, 0);
   	ins->type=STACK_I4;
   	returnins;
   	} elseif (!strcmp (cmethod->name, "get_IsDynamicCodeSupported") && !cfg->interp) {
   	EMIT_NEW_ICONST (cfg, ins, 0);
   	ins->type=STACK_I4;
   	returnins;
   	}
   	}

None of the approaches seems feasible.

---

Finally, as this change only affects app size, the verification and impact should be observable in size/perf measurements.
This will also open opportunities for further size optimisations like:

• [WIP] System.Linq.Expressions.Interpreter.CallInstruction.CanCreateArbitraryDelegates should respect IsDynamicCodeSupported #86758
• LambdaExpression.CanCompileToIL should respect IsDynamicCodeSupported #80759

[eerhardt]

LGTM. I agree testing this change here is not really feasible at this time. Maybe if we had "dotnet-linker-tests" for iOS working, it could be possible.

[ivanpovazan]

This PR introduces conditional linker substitution for get_IsDynamicCodeSupported method when targeting ios-like platforms with mono.
The substitution is enabled when feature switch DynamicCodeSupport is set to false, which should only happen in fullAOT mode - with no interpreter fallback.

Contributes to: dotnet/macios#18340

[ghost]

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

Issue Details

---

This PR introduces conditional linker substitution for get_IsDynamicCodeSupported method when targeting ios-like platforms with mono.
The substitution is enabled when feature switch DynamicCodeSupport is set to false, which should only happen in fullAOT mode - with no interpreter fallback.

Contributes to: dotnet/macios#18340

Author:	ivanpovazan
Assignees:	ivanpovazan
Labels:	os-ios, needs-area-label
Milestone:	-

[ivanpovazan]

/azp run runtime-ioslike

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27
not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

[steveisok]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27 not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

I think once Alex can land a fix for dotnet/sdk#25392, we would have the option of having it set in the SDK. There will likely need to be properties for nativeaot and monoaot.

[lewing]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27 not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

I think once Alex can land a fix for dotnet/sdk#25392, we would have the option of having it set in the SDK. There will likely need to be properties for nativeaot and monoaot.

You can set it in WorkloadManifest.targets now

[lewing]

The linker substitution doesn't look conditional to me?

[ivanpovazan]

@lewing thanks for your input, I have a couple of questions:

You can set it in WorkloadManifest.targets now

• Is this the right place? https://github.com/dotnet/runtime/blob/84a7be769fa9054dac7a973dda538cf61a488e56/src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Current.Manifest/WorkloadManifest.targets.in

• Are WorkloadManifest.targets imported in xamarin/maui projects?

The linker substitution doesn't look conditional to me?

• feature="System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported" featurevalue="false" makes it conditional in the sense that the method get_IsDynamicCodeSupported() will be replaced with false by the trimmer if the DynamicCodeSupport feature switch is set to false. Otherwise, there will be no substitution.

[marek-safar]

This needs to be wired up into some internal msbuild property otherwise it has no effect because we don't want anyone to change this manually.

[ivanpovazan]

This needs to be wired up into some internal msbuild property otherwise it has no effect because we don't want anyone to change this manually.

Agreed.
I propose as a mid-term solution to set DynamicCodeSupport around here: https://github.com/xamarin/xamarin-macios/blob/cc35efe4bc46f2aa32a0190356cedaad2723e266/dotnet/targets/Xamarin.Shared.Sdk.targets#L118-L122 once this PR lands.
As a long-term solution, it will be set in the SDK once the work dotnet/sdk#25392 is completed.

Do you agree @marek-safar ?

[ivanpovazan]

/cc: @lambdageek

[ivanpovazan]

/azp run runtime-ioslike

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

Failures seem unrelated

[ivanpovazan]

I have removed the previously added test as this set up is not unit testable for which I have considered:

1. Using reflection to test whether a code path guarded by RuntimeFeature.IsDynamicCodeSupported is preserved; but in that case ILLink will preserve dependencies that are referenced dynamically (through reflection) defeating the purpose of the test
2. Manually setting AppContext.SetSwitch("System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported", true); and making sure it does not have any effect. However, in that case MonoAOT actually does not look into managed side (and the AppContext) when determining the value for RuntimeFeature.IsDynamicCodeSupported, instead it performs an instrinsic optimisation:

   runtime/src/mono/mono/mini/intrinsics.c

   Lines 2116 to 2133 in ed26344

   	// On FullAOT, return false for RuntimeFeature:
   	// - IsDynamicCodeCompiled
   	// - IsDynamicCodeSupported and no interpreter
   	// otherwise use the C# code in System.Private.CoreLib
   	if (in_corlib&&
   	cfg->full_aot&&
   	!strcmp ("System.Runtime.CompilerServices", cmethod_klass_name_space) &&
   	!strcmp ("RuntimeFeature", cmethod_klass_name)) {
   	if (!strcmp (cmethod->name, "get_IsDynamicCodeCompiled")) {
   	EMIT_NEW_ICONST (cfg, ins, 0);
   	ins->type=STACK_I4;
   	returnins;
   	} elseif (!strcmp (cmethod->name, "get_IsDynamicCodeSupported") && !cfg->interp) {
   	EMIT_NEW_ICONST (cfg, ins, 0);
   	ins->type=STACK_I4;
   	returnins;
   	}
   	}

None of the approaches seems feasible.

---

Finally, as this change only affects app size, the verification and impact should be observable in size/perf measurements.
This will also open opportunities for further size optimisations like:

• [WIP] System.Linq.Expressions.Interpreter.CallInstruction.CanCreateArbitraryDelegates should respect IsDynamicCodeSupported #86758
• LambdaExpression.CanCompileToIL should respect IsDynamicCodeSupported #80759

[eerhardt]

LGTM. I agree testing this change here is not really feasible at this time. Maybe if we had "dotnet-linker-tests" for iOS working, it could be possible.

[ivanpovazan]

This PR introduces conditional linker substitution for get_IsDynamicCodeSupported method when targeting ios-like platforms with mono.
The substitution is enabled when feature switch DynamicCodeSupport is set to false, which should only happen in fullAOT mode - with no interpreter fallback.

Contributes to: dotnet/macios#18340

[ghost]

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

Issue Details

---

This PR introduces conditional linker substitution for get_IsDynamicCodeSupported method when targeting ios-like platforms with mono.
The substitution is enabled when feature switch DynamicCodeSupport is set to false, which should only happen in fullAOT mode - with no interpreter fallback.

Contributes to: dotnet/macios#18340

Author:	ivanpovazan
Assignees:	ivanpovazan
Labels:	os-ios, needs-area-label
Milestone:	-

[ivanpovazan]

/azp run runtime-ioslike

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27
not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

[steveisok]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27 not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

I think once Alex can land a fix for dotnet/sdk#25392, we would have the option of having it set in the SDK. There will likely need to be properties for nativeaot and monoaot.

[lewing]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27 not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

I think once Alex can land a fix for dotnet/sdk#25392, we would have the option of having it set in the SDK. There will likely need to be properties for nativeaot and monoaot.

You can set it in WorkloadManifest.targets now

[lewing]

The linker substitution doesn't look conditional to me?

[ivanpovazan]

@lewing thanks for your input, I have a couple of questions:

You can set it in WorkloadManifest.targets now

• Is this the right place? https://github.com/dotnet/runtime/blob/84a7be769fa9054dac7a973dda538cf61a488e56/src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Current.Manifest/WorkloadManifest.targets.in

• Are WorkloadManifest.targets imported in xamarin/maui projects?

The linker substitution doesn't look conditional to me?

• feature="System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported" featurevalue="false" makes it conditional in the sense that the method get_IsDynamicCodeSupported() will be replaced with false by the trimmer if the DynamicCodeSupport feature switch is set to false. Otherwise, there will be no substitution.

[marek-safar]

This needs to be wired up into some internal msbuild property otherwise it has no effect because we don't want anyone to change this manually.

[ivanpovazan]

This needs to be wired up into some internal msbuild property otherwise it has no effect because we don't want anyone to change this manually.

Agreed.
I propose as a mid-term solution to set DynamicCodeSupport around here: https://github.com/xamarin/xamarin-macios/blob/cc35efe4bc46f2aa32a0190356cedaad2723e266/dotnet/targets/Xamarin.Shared.Sdk.targets#L118-L122 once this PR lands.
As a long-term solution, it will be set in the SDK once the work dotnet/sdk#25392 is completed.

Do you agree @marek-safar ?

[ivanpovazan]

/cc: @lambdageek

[ivanpovazan]

/azp run runtime-ioslike

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

Failures seem unrelated

[ivanpovazan]

I have removed the previously added test as this set up is not unit testable for which I have considered:

1. Using reflection to test whether a code path guarded by RuntimeFeature.IsDynamicCodeSupported is preserved; but in that case ILLink will preserve dependencies that are referenced dynamically (through reflection) defeating the purpose of the test
2. Manually setting AppContext.SetSwitch("System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported", true); and making sure it does not have any effect. However, in that case MonoAOT actually does not look into managed side (and the AppContext) when determining the value for RuntimeFeature.IsDynamicCodeSupported, instead it performs an instrinsic optimisation:

   runtime/src/mono/mono/mini/intrinsics.c

   Lines 2116 to 2133 in ed26344

   	// On FullAOT, return false for RuntimeFeature:
   	// - IsDynamicCodeCompiled
   	// - IsDynamicCodeSupported and no interpreter
   	// otherwise use the C# code in System.Private.CoreLib
   	if (in_corlib&&
   	cfg->full_aot&&
   	!strcmp ("System.Runtime.CompilerServices", cmethod_klass_name_space) &&
   	!strcmp ("RuntimeFeature", cmethod_klass_name)) {
   	if (!strcmp (cmethod->name, "get_IsDynamicCodeCompiled")) {
   	EMIT_NEW_ICONST (cfg, ins, 0);
   	ins->type=STACK_I4;
   	returnins;
   	} elseif (!strcmp (cmethod->name, "get_IsDynamicCodeSupported") && !cfg->interp) {
   	EMIT_NEW_ICONST (cfg, ins, 0);
   	ins->type=STACK_I4;
   	returnins;
   	}
   	}

None of the approaches seems feasible.

---

Finally, as this change only affects app size, the verification and impact should be observable in size/perf measurements.
This will also open opportunities for further size optimisations like:

• [WIP] System.Linq.Expressions.Interpreter.CallInstruction.CanCreateArbitraryDelegates should respect IsDynamicCodeSupported #86758
• LambdaExpression.CanCompileToIL should respect IsDynamicCodeSupported #80759

[eerhardt]

LGTM. I agree testing this change here is not really feasible at this time. Maybe if we had "dotnet-linker-tests" for iOS working, it could be possible.

[ivanpovazan]

This PR introduces conditional linker substitution for get_IsDynamicCodeSupported method when targeting ios-like platforms with mono.
The substitution is enabled when feature switch DynamicCodeSupport is set to false, which should only happen in fullAOT mode - with no interpreter fallback.

Contributes to: dotnet/macios#18340

[ghost]

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

Issue Details

---

This PR introduces conditional linker substitution for get_IsDynamicCodeSupported method when targeting ios-like platforms with mono.
The substitution is enabled when feature switch DynamicCodeSupport is set to false, which should only happen in fullAOT mode - with no interpreter fallback.

Contributes to: dotnet/macios#18340

Author:	ivanpovazan
Assignees:	ivanpovazan
Labels:	os-ios, needs-area-label
Milestone:	-

[ivanpovazan]

/azp run runtime-ioslike

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27
not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

[steveisok]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27 not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

I think once Alex can land a fix for dotnet/sdk#25392, we would have the option of having it set in the SDK. There will likely need to be properties for nativeaot and monoaot.

[lewing]

NativeAOT sets the feature switch in the sdk: https://github.com/dotnet/sdk/blob/9ca8336afab6247a22e745c2de4960e9b660d164/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L27 not sure if there is another place (except in Xamarin sdk) to set it for Mono (apart from dotnet/runtime functional testing)

I think once Alex can land a fix for dotnet/sdk#25392, we would have the option of having it set in the SDK. There will likely need to be properties for nativeaot and monoaot.

You can set it in WorkloadManifest.targets now

[lewing]

The linker substitution doesn't look conditional to me?

[ivanpovazan]

@lewing thanks for your input, I have a couple of questions:

You can set it in WorkloadManifest.targets now

• Is this the right place? https://github.com/dotnet/runtime/blob/84a7be769fa9054dac7a973dda538cf61a488e56/src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Current.Manifest/WorkloadManifest.targets.in

• Are WorkloadManifest.targets imported in xamarin/maui projects?

The linker substitution doesn't look conditional to me?

• feature="System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported" featurevalue="false" makes it conditional in the sense that the method get_IsDynamicCodeSupported() will be replaced with false by the trimmer if the DynamicCodeSupport feature switch is set to false. Otherwise, there will be no substitution.

[marek-safar]

This needs to be wired up into some internal msbuild property otherwise it has no effect because we don't want anyone to change this manually.

[ivanpovazan]

This needs to be wired up into some internal msbuild property otherwise it has no effect because we don't want anyone to change this manually.

Agreed.
I propose as a mid-term solution to set DynamicCodeSupport around here: https://github.com/xamarin/xamarin-macios/blob/cc35efe4bc46f2aa32a0190356cedaad2723e266/dotnet/targets/Xamarin.Shared.Sdk.targets#L118-L122 once this PR lands.
As a long-term solution, it will be set in the SDK once the work dotnet/sdk#25392 is completed.

Do you agree @marek-safar ?

[ivanpovazan]

/cc: @lambdageek

[ivanpovazan]

/azp run runtime-ioslike

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

Failures seem unrelated

[ivanpovazan]

I have removed the previously added test as this set up is not unit testable for which I have considered:

1. Using reflection to test whether a code path guarded by RuntimeFeature.IsDynamicCodeSupported is preserved; but in that case ILLink will preserve dependencies that are referenced dynamically (through reflection) defeating the purpose of the test
2. Manually setting AppContext.SetSwitch("System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported", true); and making sure it does not have any effect. However, in that case MonoAOT actually does not look into managed side (and the AppContext) when determining the value for RuntimeFeature.IsDynamicCodeSupported, instead it performs an instrinsic optimisation:

   runtime/src/mono/mono/mini/intrinsics.c

   Lines 2116 to 2133 in ed26344

   	// On FullAOT, return false for RuntimeFeature:
   	// - IsDynamicCodeCompiled
   	// - IsDynamicCodeSupported and no interpreter
   	// otherwise use the C# code in System.Private.CoreLib
   	if (in_corlib&&
   	cfg->full_aot&&
   	!strcmp ("System.Runtime.CompilerServices", cmethod_klass_name_space) &&
   	!strcmp ("RuntimeFeature", cmethod_klass_name)) {
   	if (!strcmp (cmethod->name, "get_IsDynamicCodeCompiled")) {
   	EMIT_NEW_ICONST (cfg, ins, 0);
   	ins->type=STACK_I4;
   	returnins;
   	} elseif (!strcmp (cmethod->name, "get_IsDynamicCodeSupported") && !cfg->interp) {
   	EMIT_NEW_ICONST (cfg, ins, 0);
   	ins->type=STACK_I4;
   	returnins;
   	}
   	}

None of the approaches seems feasible.

---

Finally, as this change only affects app size, the verification and impact should be observable in size/perf measurements.
This will also open opportunities for further size optimisations like:

• [WIP] System.Linq.Expressions.Interpreter.CallInstruction.CanCreateArbitraryDelegates should respect IsDynamicCodeSupported #86758
• LambdaExpression.CanCompileToIL should respect IsDynamicCodeSupported #80759

[eerhardt]

LGTM. I agree testing this change here is not really feasible at this time. Maybe if we had "dotnet-linker-tests" for iOS working, it could be possible.