Replace heap-allocated temporary byte arrays with ArrayPool<byte>.Shared rentals in CipherStream and Streams to reduce GC pressure on hot I/O paths

[paulomorgado]

Describe your changes

Replace heap-allocated temporary byte arrays with ArrayPool<byte>.Shared rentals in CipherStream and Streams to reduce GC pressure on hot I/O paths.

Both CipherStream and Streams are used heavily in cryptographic I/O pipelines where temporary buffers are allocated on every read/write call. These short-lived allocations put unnecessary pressure on the garbage collector. ArrayPool<byte>.Shared avoids this by reusing buffers from a shared pool.

CipherStream.cs

Method	Before	After
Write(byte[], int, int)	new byte[outputSize]	ArrayPool.Rent / Return under NETCOREAPP2_0_OR_GREATER
WriteAsync(byte[], int, int)	new byte[outputSize]	ArrayPool.Rent with async ownership transfer via WriteAsyncArrayPoolCompletion
Write(ReadOnlySpan<byte>)	stackalloc / new byte[]	stackalloc / ArrayPool.Rent
WriteAsync(ReadOnlyMemory<byte>)	new byte[outputSize]	ArrayPool.Rent with async ownership transfer via WriteAsyncCompletion
Dispose(bool)	stackalloc / new byte[]	stackalloc / ArrayPool.Rent

Streams.cs

Method	Before	After
CopyTo	stackalloc / new byte[]	stackalloc / ArrayPool.Rent
CopyToAsync	new byte[bufferSize]	ArrayPool.Rent / Return
ReadAsyncCompletion	new byte[buffer.Length]	ArrayPool.Rent, deferred into async method body
WriteAsyncCompletion	buffer.ToArray()	ArrayPool.Rent, deferred into async method body

Design notes

• Ownership transfer in async methods: When a rented buffer must outlive the synchronous portion of a method (because it's passed to an async write), ownership is transferred to a completion helper that returns the buffer in its finally block. The synchronous finally only returns the buffer if no async handoff occurred (checked via length == 0).
• stackalloc / ArrayPool pattern: For synchronous Span-based methods, small buffers still use stackalloc for zero-allocation fast paths. Only the large-buffer fallback uses ArrayPool (previously new byte[]).
• clearArray: true: All ArrayPool.Return calls use clearArray: true to zero sensitive cryptographic data before the buffer is returned to the pool, matching the previous Array.Clear / Span.Fill(0x00) behavior.
• Conditional compilation: New ArrayPool usage in methods shared across all TFMs is gated behind #if NETCOREAPP2_0_OR_GREATER || NETSTANDARD2_1_OR_GREATER, falling back to the original new byte[] allocation for older targets.

How has this been tested?

Build verified across all target frameworks (net461, netstandard2.0, net6.0) with 0 errors.

Checklist before requesting a review

• I have performed a self-review of my code
• I have kept the patch limited to only change the parts related to the patch
• This change requires a documentation update

See also Contributing Guidelines.

[peterdettman]

We actually went to some trouble to remove all usage of ArrayPool.Shared, because a buffer you get from the pool is not guaranteed to have been released by all other callers (for the simple reason that one can call Return and yet retain the array). I was actually a bit shocked to realise that Stream silently exposes one's data in this way.

Possibly an internal (to BC), private (so that we can relatively guarantee release) pool could work, but even a per-library instance like this (possibly shared across separate user contexts) would be a bit concerning; I would probably prefer to see explicit security contexts of some kind, within (each of) which pooling would then be considered locally safe. Happy to hear other opinions.

[paulomorgado]

When that happens, it will cause issues for a lot of things in .NET.

Including BC, because you have no control on the usage of ArrayPool<byte>.Shared by .NET components like Stream.

Using a dedicated ArrayPool<byte> is possible, but it would just be wasting memory, because the problem you claim to be solving with that is unsolvable.