[mono] Unify invoke code with coreclr #72717

BrzVlad · 2022-07-23T11:03:29Z

Unification of invoke paths enables use of IL Emit Invoke also on mono.

InternalInvoke now receives arguments byref, enabling support for future APIs making use of this.

dotnet-issue-labeler · 2022-07-23T11:03:35Z

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

ghost · 2022-07-23T11:05:05Z

Tagging subscribers to this area: @dotnet/area-system-reflection
See info in area-owners.md if you want to be subscribed.

Issue Details

#68928

Author:	BrzVlad
Assignees:	BrzVlad
Labels:	`area-System.Reflection`
Milestone:	-

src/mono/mono/metadata/icall.c

vargaz · 2022-07-24T11:18:46Z

src/mono/mono/metadata/icall.c

+
+		if (!obj) {
+			MonoObjectHandle obj_h = mono_object_new_handle (m->klass, error);
+			goto_if_nok (error, return_null);


Might be better to use the non _handle functions and MONO_HANDLE_PIN () in this function.

src/mono/mono/metadata/icall.c

srxqds · 2022-08-04T13:40:23Z

hi, this will merge to rc1?

marek-safar · 2022-09-29T07:13:19Z

Could you look into fixing this for DynamicMethod as well?

BrzVlad · 2022-09-29T15:11:57Z

Could you look into fixing this for DynamicMethod as well?

Not sure what you mean by this. Most of the code for invoking a DynamicMethod is shared now.

src/mono/mono/metadata/icall.c

marek-safar · 2022-11-14T14:40:38Z

src/mono/System.Private.CoreLib/src/System/RuntimeMethodHandle.cs

-        // Temporary placeholder until Mono adds support for supporting boxing true Nullables.
-        internal static object? ReboxFromNullable(object? src) => src;
+        [MethodImplAttribute(MethodImplOptions.InternalCall)]
+        private static extern void ReboxFromNullable (object? src, ObjectHandleOnStack res);


Are these same as https://github.com/dotnet/runtime/blob/main/src/mono/System.Private.CoreLib/src/System/Nullable.Mono.cs#L17-L39 ?

No. Methods in Nullable.Mono.cs translate between normal boxed valuetypes and nullable structures, while these icalls translate between normal boxed valuetypes and boxed nullable structures.

This version doesn't receive a MonoArray of params as objects, rather a simple array of byrefs. There is also no need for special handling for nullables. The runtime invoke wrapper receives a boxed nullable, this conversion happens in managed code using ReboxFromNullable and ReboxToNullable. This change might have some side effects on other API making use of the runtime invoke wrapper!

Behavior was changed recently.

Aside from perf optimization, this allows the usage of LocalAppContextSwitches for invoke tests. Before this change, invoke machinery was initialized before the appcontext properties were set, failing to detect ForceInterpretedInvoke and ForceEmitInvoke properties. CoreCLR also hardcodes string type param.

This API already receives a boxed nullable now.

CoreCLR achieves this via NextCallReturnAddress. Add another intrinsic to be used for mono.

Remove special handling for nullables and throwing of NullByRefReturnException.

Which was still used only by mono_runtime_invoke_array

Nullable<T> only has 1 param constructor that creates a boxed vtype

With same behavior as before, except we have to handle conversions between nullable and boxedvt ourserlves, since it is no longer done by the runtime invoke wrapper.

… method overrides Seems to be possible via reflection, ex System.Reflection.Emit.Tests.MethodBuilderDefineMethodOverride.DefineMethodOverride_CalledTwiceWithSameBodies_Works

BrzVlad · 2022-11-17T18:06:57Z

can we merge this ?

ghost assigned BrzVlad Jul 23, 2022

BrzVlad added the area-System.Reflection label Jul 23, 2022