Uh oh!
There was an error while loading. Please reload this page.
[mono] Unify invoke code with coreclr - #72717
Conversation
ghost
commented
Jul 23, 2022
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
commented
Jul 23, 2022
Tagging subscribers to this area: @dotnet/area-system-reflection |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Might be better to use the non _handle functions and MONO_HANDLE_PIN () in this function.
Uh oh!
There was an error while loading. Please reload this page.
srxqds
commented
Aug 4, 2022
hi, this will merge to rc1? |
dd5ab0e to
2d374e5Compared256579 to
63ede38Compare061bb7a to
d0d180bComparea76abee to
c0268a5Comparemarek-safar
commented
Sep 29, 2022
Could you look into fixing this for DynamicMethod as well? |
BrzVlad
commented
Sep 29, 2022
Not sure what you mean by this. Most of the code for invoking a DynamicMethod is shared now. |
Uh oh!
There was an error while loading. Please reload this page.
5300688 to
1ed045dCompareThere was a problem hiding this comment.
There was a problem hiding this comment.
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
1ed045d to
93ca85fCompareBrzVlad
commented
Nov 17, 2022
can we merge this ? |
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.
Fixes#68928
Fixes#67457