You are viewing a plain text version of this content. The canonical link for it is here.
Posted to github@arrow.apache.org by "zeroshade (via GitHub)" <gi...@apache.org> on 2023/04/19 15:13:30 UTC

[GitHub] [arrow] zeroshade commented on issue #35232: [Go] [Question]: Retain/Release benchmarks vs Go garbage collection

zeroshade commented on issue #35232:
URL: https://github.com/apache/arrow/issues/35232#issuecomment-1514914698

   To my knowledge I don't believe a benchmark has actually been done around it as those predate the original donation of the code from InfluxDB to the repository.
   
   In theory, if you *know* you're using the default Go allocator, you don't actually have to call `Retain`/`Release` in your consumer code and can just let the Go garbage collector manage everything. We just need to make sure that we're calling `Retain`/`Release` internally here in the library so that *if* a consumer is using a non-Go-GC allocator we can be sure that they won't end up with memory leaks.
   
   The primary reasons for their existence currently are:
   * Allowing the user to control when buffers and internals are set to nil to be marked for garbage collection early if possible
   * Allowing for proper usage of allocators that don't rely on the Go garbage collector (such as the `mallocator` impl which uses malloc/free to manage C memory instead of Go garbage collection) if a user desires. 
   * While a finalizer could be utilized via `SetFinalizer` the general advice is that it's better to have an explicit release rather than relying on a finalizer since there's no actual guarantee that finalizers will ever run. In addition, finalizers only run during GC, which means that if your allocator is allocating C memory or something and the Go memory stays low it's possible that you'll end up with a ton of C memory allocated blowing out your memory before any finalizers run to actually call free on things. 
   
   


-- 
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: github-unsubscribe@arrow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org