Implement pinned flavors of GC.Allocate[Uninitialized]Array on Mono

[VSadov]

System.GC is exposing new APIs. (see: #33526)

public static T[] AllocateArray<T>(int length, bool pinned = false);
public static T[] AllocateUninitializedArray<T>(int length, bool pinned = false);

The "pinned" part guarantees that the allocated object will never be relocated.
The easiest way to implement these is to allocate in a part of the heap that is never compacted.

[davidfowl]

@VSadov are you planning to do any work on the ASP.NET Core SlabMemoryPool with these APIs?

[VSadov]

@davidfowl - it would be interesting. The biggest advantage of using pinned heap is to reduce fragmentation of regular heap. However SlabMemoryPool lives in LOH, so that is not an issue.
I think a few things could be simplified around pinned handle use.

[lambdageek]

@BrzVlad Not sure if it's obvious to you but it wasn't obvious to me: if pinned == true, it doesn't mean the object is kept alive forever. But if the object is alive, it is at a fixed location. So it's like a weak but pinned gchandle. (I'm just restating what's in #27146 (comment))

[BrzVlad]

Yes, that was my expectation. We already have this mechanism, in order to implement this we just need to expose mono_gc_alloc_pinned_obj to the api

[VSadov]

Yes, it is just a regular object that does not move. the behavior could be implemented using some combination of weak/pinning handles.

However, the key advantage comes from not having these in regular compactible heap. If you have a heap region that does not compact (like large object heap or smth), forcing these objects to live there could be a better solution.

[VSadov]

Also note - the API currently forbids arrays with references. There are no fundamental reasons to have such restriction. It just was not clear whether anyone needs this or not.
It actually works internally, so the restriction may be relaxed if there is demand.