[API Proposal]: GCHandle.GetTargetUnsafe() with no handle validation

[Sergio0694]

Background and motivation

GCHandle is often used in scenarios (such as handwritten COM objects, or other interop setups) where callers have complete control over the handles, and nobody else is ever mutating them. The only way, currently, to get a target, is to use GCHandle.Target, which always incurs in a validation check, which is pretty much always just useless branching in these cases.

This proposal is about adding a way to get the handle target with no branches, when callers know no validation is needed.

API Proposal

namespace System.Runtime.InteropServices;

public struct GCHandle
{
+   public readonly object? GetTargetUnsafe();
}

API Usage

// In a constructor (or wherever)
this.handle = GCHandle.Alloc(myObj);

// Later on
object? target = this.handle.GetTargetUnsafe();

Alternative Designs

Alternatively (as @tannergooding also suggested), we could instead just remove the validation check from GCHandle.Target. This would technically be a breaking change, as it would cause invalid handles to throw a NullReferenceException instead of an InvalidOperationException, but it might be considered acceptable in this scenario, since it's a niche API.

The benefit of this approach is that no new API is needed, and everyone "gets faster for free".

Risks

With the new API, no risk.
With the alternate design, people taking a hard dependency on that exception type would break.

[tannergooding]

Alternatively (as @tannergooding also suggested), we could instead just remove the validation check from GCHandle.Target. This would technically be a breaking change, as it would cause invalid handles to throw a NullReferenceException instead of an InvalidOperationException, but it might be considered acceptable in this scenario, since it's a niche API.

Notably this suggestion came from the perspective that the current implementation is logically:

ThrowIfInvalid(handle);
handle &= ~(nuint)(1); // strip the pin bit
return InternalGet(handle);

This means that these two calls should be logically the same, but they aren't:

GCHandle.FromIntPtr(0).Target; // InvalidOperation
GCHandle.FromIntPtr(1).Target; // NullReference

We're already handling all kinds of invalid handles and most of them, outside 0, result in a NRE. So it might make sense to simply have 0 also cause a NRE. This removes the branch and makes the API overall more consistent.

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and motivation

GCHandle is often used in scenarios (such as handwritten COM objects, or other interop setups) where callers have complete control over the handles, and nobody else is ever mutating them. The only way, currently, to get a target, is to use GCHandle.Target, which always incurs in a validation check, which is pretty much always just useless branching in these cases.

This proposal is about adding a way to get the handle target with no branches, when callers know no validation is needed.

API Proposal

namespace System.Runtime.InteropServices;

public struct GCHandle
{
+   public readonly object? GetTargetUnsafe();
}

API Usage

// In a constructor (or wherever)
this.handle = GCHandle.Alloc(myObj);

// Later on
object? target = this.handle.GetTargetUnsafe();

Alternative Designs

Alternatively (as @tannergooding also suggested), we could instead just remove the validation check from GCHandle.Target. This would technically be a breaking change, as it would cause invalid handles to throw a NullReferenceException instead of an InvalidOperationException, but it might be considered acceptable in this scenario, since it's a niche API.

The benefit of this approach is that no new API is needed, and everyone "gets faster for free".

Risks

With the new API, no risk.
With the alternate design, people taking a hard dependency on that exception type would break.

Author:	Sergio0694
Assignees:	-
Labels:	api-suggestion, area-System.Runtime.InteropServices, untriaged, needs-area-label
Milestone:	-

[jkotas]

There are other similar inefficiencies in GCHandle:

• Useless Interlocked operation in "Free" method (Add Dispose/IDisposable to GCHandle #54792 (comment))
• The bit for tracking whether the GCHandle is pinned that needs to be cleared on every access

And there is the cosmetic issue of GCHandle not implementing IDisposable (#54792).

We should consider all of them at the same time. We may want to consider introducing a new type that has all of them fixed.

[Sergio0694]

That type looks really nice 👀

If there is interest, what about opening a new proposal for that, linking all these ones, and try to get that to API review?

[Sergio0694]

Superseded by #94134, closing this.