Add GCHandleType.UnsafelyPinned or similar to address limitations

[jthorborg]

A GCHandle doesn't allow to recover the address of a managed object if it contains non-primitive or non-blittable data.

The reasoning for this is scattered a bit but usually falls under the realm of "you shouldn't do that" or "what you're trying to do is unsafe because [assumptions about use case]". Specifically, it seems responders imagine that the use case is either of:

1. Read a layout externally (like in C), without marshalling
2. Offsetting into the data, writing through a void pointer

Both of these are obviously unsafe, and 2) isn't quite possible anyway as you can't obtain unmarshalled fieldoffsets legally anyway. But... There's a third, safe use case being unreasonably blocked here.

Forming a persistent, type erased pointer to value types living in GC memory, that can be resolved to a reference that typed code can write into.

Okay, so that seems a little arcane, but imagine a pooled system of user-extensible types. You have a list of these and want to call an interface function on these.

interface INode 
{
	void DoSomething();
}

delegate* void Callback(void*);

static class Trampoline<TNode>
	where TNode : struct, INode
{
	static void Something(void* _this)
	{
		Unsafe.AsRef<TNode>(_this).DoSomething();
	}
}

struct Node
{
	public void* Pointer;
	public Callback Callback;

	static internal Node Create<TNode>()
		where TNode : struct, INode
	{
		Node n;
		n.Pointer = Allocate<Traits<TNode>>();
		n.Callback = &Trampoline<TNode>.Something;
	}
}

NativeList<Node> Nodes;

foreach(var n in Nodes)
	n.Callback(n.Pointer);

You will find code structure like this in many HPC games or similar, and C# is making great strides to make this much easier, but there are still artificial blockers here and there.

The attractive feature here is all of the "engine" code can use native memory, and have deterministic memory footprint and complexity. Nodes themselves can be rooted in native or managed memory depending on what is suitable, and you have a uniform interface for dealing with them.

You will also notice that any writes happening to the pointer is completely type safe and what the runtime expects, as it is typed code (so long as you rigged the traits correctly together - hence Unsafe on the API).

Thoughts?

Appendix.

1. You should use classes! Extra indirections and indeterministic GC pressure, hard to root from unmanaged memory, incompatible with native code
2. Boxing solves this! Well, it creates GC pressure, you need a GC handle to root it, and you have to copy back and forth every dereference.
3. GCHandle! Well, see above.

Essentially the problem is you don't have a way of referring to a managed value type in GC memory that you can read and write to by reference. It can sort of be faked with an array.

Common for all these is impossibility of referring "by reference" to an element of an array, which is what you're doing when you're pooling objects tightly together. Pointer arithmetic on a pre-pinned GC array solves this instantly.

[jthorborg]

Now implemented through an relaxation in the pinned object heap: #89293