Cache Sytem.RuntimeMethodInfoStub instances created in the VM in the MethodDesc's owning LoaderAllocator.

[jkoritzinsky]

Instead of allocating a new System.RuntimeMethodInfoStub every time MethodDesc::GetStubMethodInfo is called, lazily create the stub and cache it in the MethodDesc's LoaderAllocator.

This change was extracted out of #26340.

[davidwrighton]

I see thread contention issues, and incorrect use of HashMap. Please address.

[davidwrighton]

Putting a Crst here adds possible thread contention to an api which was previously effectively lock free.

[davidwrighton]

Instead, I would do the lookup without the lock, then take the lock, lookup again, and then add. Both the SHash infrastructure and HashMap are supposed to be able to do this.

[jkotas]

SHash does not support lock-free reads.

[davidwrighton]

Do not use HashMap directly for holding pointers. Per the comments on the PtrHashMap implementation, you should never put use a pointer as a key in a HashMap, you should always use a PtrHashMap. Of course, you can't safely store a LOADERHANDLE in a PtrHashMap, as it requires the low bit to be null on values. Instead I recommend you use a MapSHash.

[jkotas]

Why are the allocations of RuntimeMethodInfoStub a problem?

[jkoritzinsky]

In #26340, the efficient way to support marshaling arrays of non-blittable structures is to cache the MethodDesc of the struct stub. To do so, I was doing a ldtoken tokenForStructStubMD. Since the allocations of RuntimeMethodInfoStub aren't cached, that introduced an allocation into PInvoke stubs and struct stubs when a parameter/return value/field was an array of non-blittable structures.

This was my first-draft attempt at caching the allocation so we wouldn't allocate every call. Additionally, it seemed odd to me initially that the ldtoken instruction allocates when resolving a method token since it doesn't allocate for type tokens.

[jkotas]

it seemed odd to me initially that the ldtoken instruction allocates when resolving a method token since it doesn't allocate for type tokens.

RuntimeTypeHandle/System.Type vs RuntimeMethodHandle/System.Reflection.MethodInfo are very different. System.Type is used in number of fast APIs that have nothing to with reflection. MethodInfo only ever shows up in the expensive relatively slow reflection APIs, that tend to allocate a lot. I do not think that it is too surprising that this one allocates too.

[jkotas]

To do so, I was doing a ldtoken tokenForStructStubMD

What are you going to do with this token? You cannot really do anything efficient with it. I assume that you want to call the function eventually - would it be better to do ldftn tokenForStructStubMD ?

[jkoritzinsky]

I'm getting the InternalToken to pass the MethodDesc pointer back down to cache in the structure for the marshaler (since it needs to be invoked from the array marshalling which is still in native code).

Is there a way I could call from native back into managed within the runtime via a function pointer to a managed function? I've been using MethodDescCallSite so far.

[jkotas]

Take a look at PREPARE_NONVIRTUAL_CALLSITE_USING_CODE

[jkoritzinsky]

I'll take a look at it. Thanks!

[jkoritzinsky]

That worked perfectly! Thanks for the suggestion!