[API Proposal]: using support for ArrayPool

[huoyaoyuan]

Background and motivation

Currently, ArrayPool<T>.Shared is used more widely in user code and BCL code, especially async methods. Typical use cases look like:

byte[] buffer = ArrayPool<byte>.Shared.Rent(bufferLength);
try
{
    ConsumeSync(buffer.AsSpan());
    await ConsumeAsync(buffer.AsMemory());
}
finally
{
    ArrayPool<byte>.Shared.Return(buffer);
}

The try-finally pattern currently can't leverage using syntax to simplify the code. In contrast, MemoryPool<T> is providing using support through IMemoryOwner<T>:

using IMemoryOwner<byte> buffer = MemoryPool<byte>.Shared.Rent(bufferLength);
{
    ConsomeSync(buffer.Memory.Span);
    await ConsumeAsync(buffer.Memory);
}

However, MemoryPool<T> and IMemoryOwner<T> aren't suitable for many use cases of ArrayPool<T> because of the higher overhead of IMemoryOwner<T> and Memory<T>. Thus, it can be worthy to add using support for ArrayPool<T> for low overhead.

API Proposal

namespace System.Buffers;

public abstract partial class ArrayPool<T>
{
    // existing
    public abstract T[] Rent(int minimumLength);
    public abstract void Return(T[] array, bool clearArray = false);
    // new
+   public Lease RentLease(int minimumLength, bool clearOnReturn = false);
+   public struct Lease : IDisposable
+   {
+       public T[] Array { get; }
+       public void Dispose();
+   }
}

API Usage

using (var buffer = ArrayPool<T>.Shared.Rent(bufferLength))
{
    ConsumeSync(buffer.Array.AsSpan());
    await ConsumeAsync(buffer.Array.AsMemory());
}

Alternative Designs

Making RentLease virtual. Unlikely because it would create either additional performance penalty on top of Rent, or duplicated code with Rent if overridden.

Risks

When Lease is captured in async method, it will capture additional fields comparing to raw array management. The pool (usually ArrayPool<T>.Shared and additional arguments for return (clearOnReturn) need to be captured.

[dotnet-policy-service]

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

[EgorBo]

Typical use cases look like:

The typical use should not involve try-finally as it makes it fragile and vulnerable to potential use-after-free bugs (unless it is 100% predictable who/how can throw an exception)

The end goal is to hide 95% of usages with something like #52065

[stephentoub]

A struct like this also makes it even more likely to accidentally return the buffer multiple times. And using a class instead is exactly what MemoryPool provides.

With all of the deabstraction work being done by @AndyAyersMS, I would also hope that this allocation could end up frequently being implicitly stack allocated, once all the right inlining and the like happens.

[EgorBo]

With all of the deabstraction work being done by @AndyAyersMS, I would also hope that this allocation could end up frequently being implicitly stack allocated, once all the right inlining and the like happens.

Presumably, it is unlikely JIT can ever do "stackalloc or ArrayPool" under the hood for a normal allocation, only "stackalloc or heap", so an explicit API probably still good idea.
Unless we're fine with "stackalloc or heap" and the possible GC overhead

[stephentoub]

Presumably, it is unlikely JIT can ever do "stackalloc or ArrayPool" under the hood for a normal allocation, only "stackalloc or heap", so an explicit API probably still good idea.

I wasn't talking about the array allocation. Rather, I was talking about the IDisposable object wrapper it allocates for the returned array.

[huoyaoyuan]

I would also hope that this allocation could end up frequently being implicitly stack allocated

Should this cover synchronous cases only? What about the async cases?

[stephentoub]

I would also hope that this allocation could end up frequently being implicitly stack allocated

Should this cover synchronous cases only? What about the async cases?

It would hopefully cover the async cases as well in the 99% case once the new async support lands in the runtime.