On Fri, Sep 22, 2017 at 6:54 AM, Remus Clearwater <remus.clearwa...@gmail.com> wrote: > > Hi Gernot, do you mean that the virtual address space used for `mmap` > calling by go malloc and glibc's are always different? If the virtual > address > space of go malloc and glibc's are designed to be different intentionally, > could you please tell me where I could found the specs and guarantees? > Does jemalloc/tcmalloc has this virtual address space convention too? > It is a tittle weird still, I was thought they are self-adaption.
The Go memory allocator attempts to reserve the address space it is going to use in calls to runtime.sysReserve, a function that is OS-specific. Look in the runtime package for the implementation for the operating systems that you care about. In any case, the Go allocator has data structures that record the valid addresses, and it does not give up that address space unless it knows that there are no valid Go pointers into that space. So, if the reservation scheme breaks down, it is possible that a C pointer is allocated, and then freed, and the C allocator releases the memory, but the dangling pointer survives, and the Go allocator allocates that space, and the C dangling pointer somehow gets into Go, where it is treated as a Go pointer. But that is really no different from any other way that C can create an invalid pointer and pass it into Go. If an invalid C pointer gets treated as a Go pointer, there is a bug in the program. Reusing a C pointer after it has been freed is just a special case of that. Ian -- 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. For more options, visit https://groups.google.com/d/optout.
