feat(arrow/memory): experimenting with addcleanup

[zeroshade]

Rationale for this change

Experimenting with using AddCleanup for automatic cleanup of the Buffers without requiring Retain and Release everywhere even for custom Allocators.

What changes are included in this PR?

Changes to the underlying Buffer object to leverage AddCleanup when using go1.24 or higher.

Are these changes tested?

Yes, though more tests need to be added to ensure more complex scenarios don't fail.

Are there any user-facing changes?

[lidavidm]

So the idea is that via AddCleanup we can avoid explicit retain/release calls? I suppose if it makes basic usage of the library simpler, then it makes sense. I think we should caution that for "library" code, it should not be used and retain/release should be used instead.

Is there a runtime cost to attaching the cleanup callback? An application that does intend to use retain/release may not want to pay the price if there is one.

FWIW, Java may be of interest here. Java had community libraries like Netty that effectively relied on explicit retain/release callbacks to avoid GC overhead and access native memory. The modern FFM API offers an API that is instead based around explicit "arenas", and one of the arenas is managed by the garbage collector (= no manual memory management), while others require you to close the arena (but not individual allocations). (Incidentally, arrow-java has "the worst of both worlds": both allocators and individual allocations must be closed.) That may be too restrictive of a paradigm here, though.

[zeroshade]

I suppose if it makes basic usage of the library simpler, then it makes sense. I think we should caution that for "library" code, it should not be used and retain/release should be used instead.

Would make sense to put this into the documentation.

Alternatively, we could use a build tag to control whether it uses addcleanup or not? (turn whichever isn't in use into no-ops)

Is there a runtime cost to attaching the cleanup callback? An application that does intend to use retain/release may not want to pay the price if there is one.

Yes, there's a runtime cost to attaching the cleanup callback (albeit, AFAIK it's very small). In theory, it would be overall cheaper for the AddCleanup solution vs the repeated calls for Retain and Release.

One important caveat to keep in mind (that technically still exists even with the current retain/release paradigm) is that users should never maintain a reference to the []byte from the Bytes() method of memory.Buffer longer than the scope of the buffer (or call to Release). In the case of a non-go allocator, those bytes could get wiped out from under them when the releasing occurs. It may make sense to utilize the new weak.Ptr in some way for how we expose the byte slices from the buffer.

[zeroshade]

@chriscasola Given this came out of your comment on #269 would you be willing to take a look at this and give your thoughts on mine and @lidavidm's comments above?