zeroshade commented on PR #14878: URL: https://github.com/apache/arrow/pull/14878#issuecomment-1347229853
@pitrou Yes. But with the Arrow library for Go, we provide an `Allocator` interface to allow consumers to use a custom allocator rather than the default Go allocator so that they could, for instance, call out to `jemalloc` and have that manage their Arrow memory, hiding it from the Go GC so the Go GC no longer has to scan that. Or any other way they want to manage their memory. As such, the objects have `Release` and `Retain` methods to track reference counting and eagerly release memory. The DefaultAllocator is just using Go's GC and setting slices to nil, etc. when they get released. So we have a test allocator `CheckedAllocator` which can track the allocations and frees to see if there's anywhere that a buffer is kept around without having called Free on it (which would cause a memory leak if they weren't using the Default Allocator, or can cause excessive creation of objects the GC will have to clean up). That's what we're referring to as memory leaks here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
