After discussion with college, I wonder if it would be possible (even if completely does not make any sense) to deallocate memory manually in go (ie. by using unsafe package). Is it?
3
- 3No this is not possible.Volker– Volker2016-06-15 09:47:38 +00:00Commented Jun 15, 2016 at 9:47
- 1You can always deallocate memory you've manually allocated. Is that what you're looking to do?Mr_Pink– Mr_Pink2016-06-15 12:56:35 +00:00Commented Jun 15, 2016 at 12:56
- 1The language strives to make you forget about memory management, so it's understandable why they wouldn't have this feature.Ammar Bandukwala– Ammar Bandukwala2016-06-15 16:56:55 +00:00Commented Jun 15, 2016 at 16:56
Add a comment |
2 Answers
Here is a thread that may interest you: Add runtime.Free() for GOGC=off
Interesting part:
The Go GC does not have the ability to manually deallocate blocks anymore. And besides, runtime. Free is unsafe (people might free still in use pointers or double free) and then all sorts of C memory problem that Go tries hard to get rid of will come back. The other reason is that runtime sometimes allocates behind your back and there is no way for the program to explicitly free memory.
If you really want to manually manage memory with Go, implement your own memory allocator based on syscall.Mmap or cgo malloc/free.
Disabling GC for extended period of time is generally a bad solution for a concurrent language like Go. And Go's GC will only be better down the road.
TL;DR: Yes, but don't do it
Comments
I am a bit late but this question is high ranked on google, so here is an article by the creator of DGraph database which explains an alternative to malloc/calloc which is jemalloc, worth a look
https://dgraph.io/blog/post/manual-memory-management-golang-jemalloc/
With these techniques, we get the best of both worlds: We can do manual memory allocation in critical, memory-bound code paths. At the same time, we can get the benefits of automatic garbage collection in non-critical code paths. Even if you are not comfortable using Cgo or jemalloc, you could apply these techniques on bigger chunks of Go memory, with similar impact.
And I haven't tested it yet, but there is a github library called jemalloc-go
https://github.com/spinlock/jemalloc-go
Edit: Go 1.21 now includes arena. Not useful in every case but gives control over garbage collection in some usecase.
