We are having a discussion on 
https://github.com/apache/arrow/pull/3925#issuecomment-473605919 about the 
`MemoryPool` class in the C# library.

In reality, the way `MemoryPool` is designed in C#, it is more of a 
"MemoryAllocator" - it just allocates or reallocates memory. There is no API 
for "returning" the memory back into the pool. The memory gets deallocated 
because the finalizer, which is invoked by the garbage collector.

I was looking around a bit, and I see the Java library doesn't have a 
MemoryPool, but instead BufferManager and BufferAllocator types. The Java 
library also has `AutoCloseable` (which I assume is analogous to IDisposable in 
.NET) on all the types - ArrowRecordBatch, ArrowBuf, IntVector, etc.

Looking into the C++ implementation, I don't really see a "pooling" 
implementation, but instead just an "malloc" and "free" (or using jemalloc, if 
built with it enabled). I also see it is using "aligned" memory. I'm not sure 
how/what handles this on the Java side. I assume the alignment is useful for 
SIMD operations, but is it required?

Go also appears to be using the "Allocator" name instead of a "Pool".

So I'm wondering a few things:


  1.  Should we rename the C# "MemoryPool" class to "MemoryAllocator" instead? 
Or is there really an intention in Arrow to have "pooling" of memory?
  2.  Should there be a way to "close" (Dispose() in the .NET nomenclature) 
types that hold memory? Ex. RecordBatch, ArrowArray, etc.

I assume these mechanisms are super useful to the other implementations, so I'm 
trying to keep the C# library designed roughly the same. But I'd appreciate 
some advice.

Eric Erhardt

Reply via email to