Ian's advice seems sound. But there is one other option to consider. When practical, I like to simply copy C allocated memory to Go allocated memory in the wrapper for the cgo call, and free the C memory immediately. This removes the insanity of keeping track of C memory in Go. Obviously there are myriad reasons why this might not be possible, or might impose to great a penalty. But where it is possible, it makes life easy again.
On Friday, November 1, 2019 at 9:28:36 AM UTC-4, Tom Payne wrote: > > cgo is often used to provide bindings to C libraries. Any memory allocated > in the C library is not visible to Go, so Go does not have an accurate view > of the program's memory usage and does not run the garbage collector or any > finalizers often enough. Consequently, memory usage for a Go server that > uses cgo heavily can grow very large, with Go itself being utterly unaware > of it. > > If the C functions allocate memory, historically you could set a finalizer > to free the memory sometime after there are no remaining references to it > in Go, as, for example, described in this blog post > <http://rabarar.github.io/blog/2015/09/29/cgo-and-destructors-for-managing-allocated-memory-in-go/>. > > However, the current Go docs on runtime.SetFinalizer > <https://golang.org/pkg/runtime/#SetFinalizer> state: > > > There is no guarantee that finalizers will run before a program exits, > so typically they are useful only for releasing non-memory resources > associated with an object during a long-running program. > > Are there any other ways to automatically release memory resources > associated with an object? Or telling Go's memory manager that the small > object it sees in the Go world is but the tip of an iceberg of memory > allocated in the C world and therefore should be finalized? > > Not-good options include: > - Requiring the programmer to make explicit calls to free the memory > resources when they believe the object is no longer needed, but this takes > us back to the painful world of C's manual memory management and is easy to > get wrong. > - Padding Go objects associated with C memory resources with large, unused > fields (e.g. an [1024]byte) in the hope that the Go garbage collector will > be more likely to finalize and free them when they are unused. > - Avoiding cgo in any server code. > > Are there any good options? > > Cheers, > Tom > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/682feb70-e5de-400c-a14b-06e8af6140ae%40googlegroups.com.
