What exactly happens if I fail to return memory rented from the shared MemoryPool/ArrayPool?

[castholm]

Imagine I am doing something stupid like this:

for (int i = 0; i < 100; i++)
{
    _ = MemoryPool<byte>.Shared.Rent(1024);
}

Since there are no longer any references to the memory instances in my application code, will the rented memory eventually be reclaimed by the garbage collector or is it permanently lost? I've scoured through most relevant documentation but I couldn't find a clear answer. The closest thing I could find was

Failure to call the Dispose method may lead to unmanaged memory leaks or other performance degradation. [Emphasis mine]

but I suspect that this is most likely generic advice for when working with custom pooled memory implementations and might not be true for the MemoryPool<T>.Shared/ArrayPool<T>.Shared.

For context, I am passing IMemoryOwner<byte> instances around TPL Dataflow pipelines and I'm trying to understand what would happen if I fault or cancel a dataflow block and it clears its internal queue without disposing the contained elements.

[Clockwork-Muse]

Since there are no longer any references to the memory instances in my application code, will the rented memory eventually be reclaimed by the garbage collector or is it permanently lost? I've scoured through most relevant documentation but I couldn't find a clear answer.

For the default array pool (and the simple array-based Memory pool), it (as near as I can tell) releases ownership of the array memory on Rent, so the GC should collect it.

For context, I am passing IMemoryOwner<byte> instances around TPL Dataflow pipelines and I'm trying to understand what would happen if I fault or cancel a dataflow block and it clears its internal queue without disposing the contained elements.

You have potentially worse issues than a simple memory leak if your contained elements contain native resources, and you don't properly clean them up.

[castholm]

Thanks! So if I understand correctly, the default shared pool doesn't pre-allocate arrays in advance, it just retrieves previously returned arrays (or allocates new ones) and drops all internal references to them. Makes a lot of sense.

You have potentially worse issues than a simple memory leak if your contained elements contain native resources, and you don't properly clean them up.

My elements don't contain any native or unmanaged/unsafe resources, just IMemoryOwner<byte> instances that were rented from the shared pool (which is entirely managed (?)), to reduce GC pressure compared to allocating new arrays every time I need to post/send a new message.

So to my understanding, the only problem with this is that if a block is stopped without completing naturally the rented memory in the dropped messages won't be freed until the GC collects it naturally. This might not be optimal from a design/robustness standpoint, but in terms of performance and reducing GC pressure, it should still be preferable to allocating new arrays every time, right?

[Clockwork-Muse]

Yes, since in the majority case you're going to complete successfully you'll mostly be fine. In fact, if your pipeline is short enough even the failures may not move things out of Gen 0, so can be cleaned up relatively cheaply.