[WIP] Fast codegen-free generic object instantiation + improve Activator.CreateInstance perf

[GrabYourPitchforks]

(Migrated from dotnet#32520 so I can iterate here without distracting the folks in the main runtime repo. See the PR feedback there for discussion.)

---

Contributes to dotnet#23716.

This is a very rough prototype of ObjectFactory and UninitializedObjectFactory, which allow fast codegen-free instantiation of arbitrary objects. It's primarily suited for DI and other scenarios where developers need to instantiate objects whose types aren't known until runtime but are required to do so with as minimal overhead as possible.

Historically, the way to instantiate such objects is to call Activator.CreateInstance or ConstructorInfo.Invoke. However, there is some overhead to this, as checks need to take place on each reflection API invocation. Some developers who need to eke out extra performance end up creating a DynamicMethod and hand-rolling a newobj instruction into the IL stream. This provides generally acceptable results, but it is tricky to get right, there's significant per-instantiation overhead due to spinning up the JIT, it's complex to debug issues in the code gen, and it doesn't work properly in environments where code gen is unavailable.

Note: These APIs have not yet been approved, as this is just an experimental PR to gauge general interest and to solicit feedback on the design and functionality.

General philosophy

Historically, most reflection APIs like Activator.CreateInstance and ConstructorInfo.Invoke perform checks on each method invocation. We can try to reduce the cost of these checks, but due to the nature of these APIs we'll never be able to remove the checks entirely.

The UninitializedObjectFactory and ObjectFactory APIs, on the other hand, perform all of their checks at construction time, not at invocation time. This means that it may be somewhat expensive to create the factory / dispenser itself, but once the factory is created it's very cheap to request a new instance from the factory. The intent is that these factories aren't used for one-off scenarios - callers should continue to use Activator.CreateInstance and ConstructorInfo.Invoke in such code paths. But in scenarios where the same type of object will be instantiated over and over again, it's very efficient to cache a single instance of the factory per-type and to query the cached instance whenever a new T instance is needed.

UninitializedObjectFactory

The UninitializedObjectFactory type is roughly equivalent to RuntimeHelpers.GetUninitializedObject. This instantiates the type without running any instance constructors. (Static constructors are still run.) Most applications should never need this, but it is useful for library authors building their own serialization or DI frameworks on top of this. The general pattern such library authors should follow is to use UninitializedObjectFactory to create a not-yet-constructed instance of target type T, then manually invoke the appropriate constructor on the newly-allocated instance.

ObjectFactory

The ObjectFactory type is roughly equivalent to Activator.CreateInstance<T>(). It allocates the type then calls the public, parameterless instance constructor. There are two main differences between ObjectFactory.CreateInstance and Activator.CreateInstance<T>():

• If object construction fails, ObjectFactory.CreateInstance will not wrap the thrown exception within a TargetInvocationException. Activator.CreateInstance<T>() will wrap exceptions.
• If T is a value type, ObjectFactory.CreateInstance will always return default(T). Activator.CreateInstance<T>() will call T's parameterless constructor if one exists; otherwise it returns default(T).

Potential consumers

System.Text.Json

https://github.com/dotnet/runtime/blob/9d85b82e3ad856068459c8f8bba8509e038afb40/src/libraries/System.Text.Json/src/System/Text/Json/Serialization/ReflectionEmitMemberAccessor.cs#L39-L51

ASP.NET Core

dotnet/aspnetcore#14615 (though they're using TypeBuilder to work around this right now)

Other runtime + libraries

https://github.com/dotnet/runtime/blob/9d85b82e3ad856068459c8f8bba8509e038afb40/src/libraries/System.ComponentModel.Composition/src/System/ComponentModel/Composition/MetadataViewGenerator.cs#L371-L380

Inner workings

A newobj instruction is logically two operations: (a) allocate a block of zero-inited memory, then (b) call the type's instance ctor over this block of memory. (UninitializedObjectFactory skips this second step.)

// C#
object o = new object();

// MSIL
newobj instance void [System.Private.CoreLib]System.Object::.ctor()

mov rcx, 0x12345678 ; method table pointer for System.Object
call <allocator> ; when this returns, rax := zero-inited object instance
mov rcx, rax
call System.Object::.ctor() ; essentially, a static method with signature (object @this) -> void

When using Activator.CreateInstance, the runtime uses a generic allocator that can handle many different scenarios for allocating an object whose type is known only at runtime. And while this generic allocator is flexible, there's significant overhead due to all the different checks it needs to perform.

On the other hand, when JITting a newobj instruction, since the JIT knows the destination type statically, it's able to choose from a variety of allocators whose implementations are optimized for various different scenarios. For example, there exists an allocator tailored for small, non-finalizable types. There exists a different allocator tailored for finalizable types. And there exists yet another allocator that's used when instrumentation is enabled.

When an [Uninitialized]ObjectFactory<T> instance is created, it queries the runtime for the address of the allocator that would have been used for an object of type T. All allocators share the signature (MethodTable*) -> O, so once the allocator address is determined we can perform the equivalent of the following IL in order to quickly allocate the object.

ldarg.0 // assume arg 0 = MethodTable* of destination type
ldarg.1 // assume arg1 = allocator function pointer
calli object(native int)
ret

If we need to fully construct the object, then we further query the runtime for the address of the code that corresponds to the public parameterless ctor of type T. All public parameterless ctors on reference types share the signature (object) -> void, so once the ctor address is determined we can perform the equivalent of the following IL in order to quickly call the ctor.

ldarg.0 // assume arg 0 = return value from UninitializedObjectFactory.CreateUninitializedInstance()
ldarg.1 // assume arg 1 = public parameterless ctor function pointer
calli void(object)
ret

Putting this all together, we get the following pseudo-codegen for ObjectFactory<T>.CreateInstance.

mov rcx, qword ptr [@this + <offset_to_methodtableptr_field>]
call qword ptr [@this + <offset_to_allocatorptr_field>]
mov rcx, rax
call qword ptr [@this + <offset_to_ctorptr_field>]
ret

Performance

Below are preliminary numbers for various "create an object" scenarios. Calling new object() directly is the baseline.

Method	Mean	Ratio	Scenario
DirectNewobj	4.011 ns	1.00	Calling new object() directly
DynamicMethodNewobj	5.527 ns	1.31	Calling a cached DynamicMethod whose IL stream reads newobj [object]; ret;
ObjectFactoryCreateInstance	4.937 ns	1.23	Calling a cached ObjectFactory<object>'s CreateInstance method

I've also experimented with plumbing this through the existing Activator.CreateInstance pipeline. The perf numbers are not as good as calling ObjectFactory.CreateInstance directly because there's still overhead to querying the static cache and performing any necessary checks, and there's some compat behavior such as TargetInvocationException wrapping that we can't avoid, but they still show a significant improvement over the baseline (master branch) Activator.CreateInstance numbers.

Method	Toolchain	Mean	Error	StdDev	Ratio	RatioSD
ActivatorCreateInstance	master	40.55 ns	0.889 ns	1.156 ns	1.00	0.00
ActivatorCreateInstance	objectfactory	14.54 ns	0.362 ns	0.303 ns	0.36	0.01
ActivatorCreateInstanceOfT	master	42.17 ns	0.917 ns	1.581 ns	1.00	0.00
ActivatorCreateInstanceOfT	objectfactory	16.86 ns	0.409 ns	0.613 ns	0.40	0.02

And for RuntimeHelpers.GetUninitializedObject(typeof(object)) vs. UninitializedObjectFactory<object>.CreateUninitializedInstance():

Method	Mean	Ratio
RH_GetUninitializedObject	40.377 ns	1.00
UninitializedObjectFactory	3.588 ns	0.09

Remaining work

• Continue with code cleanup and testing edge cases like trying to instantiate arrays.
• Support parameterful ctors; e.g., new T(IServiceProvider).
• Convert the code to use calli support when it's natively available in C#.
• Full API review.
• Support for Mono + CoreRT.

[GrabYourPitchforks]

A status update - I'm still working on this but keep running into issues where the linker either crashes or trims a method which is clearly statically reachable. Trying to work around those before sending up a new iteration. Meanwhile I've reduced the scope of the work so that it's not adding any new APIs in the 5.0 timeframe.

[GrabYourPitchforks]

Closing since this is going into the real runtime branch imminently.