I recently read this article http://codearcana.com/posts/2012/05/06/securing-and-exploiting-go-binaries.html which claims in Go that the heap is executable. This raises a few different questions for me about the interaction between the runtime and the operating system.
In C, when a program needs space on the heap, it makes a call to malloc, which in turn calls sbrk which gives it memory. As far as I know in C the heap is read-write only.
Why is the heap in Go executable? What is different about the application - OS interaction in Go then in C?
Thanks
All goroutines share a common heap and anything that can't be stored on the stack will end up there. When a heap allocation occurs in a function being benchmarked, we'll see the allocs/ops stat go up by one. It's the job of the garbage collector to later free heap variables that are no longer referenced.
Go uses OS function mmap similar to TCMalloc (Thread-Caching Malloc) to allocate memory in heap. Go uses goroutine, which maintain a small stack (memory segment) act as memory pool for some memory blocks. The maximum stack size is 1 GB on 64-bit systems, and 250 MB on 32-bit systems, can be set by SetMaxStack function.
Stored in computer RAM just like the stack.
Stack memory allocation is considered safer as compared to heap memory allocation because the data stored can only be access by owner thread. Memory allocation and de-allocation is faster as compared to Heap-memory allocation.
The heap is no longer executable.
Code was generated at runtime for function literals prior to Go 1.1, thus requiring an executable heap. Function calls were revamped in Go 1.1 to eliminate the need for an executable heap and to provide other benefits.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With