C/C++ runtime library allocations and Go memory allocation do not "overlap". C/C++ runtime and Go heap will reserve memory pages on which they operate from the operating system. This will ensure, that both memory management systems will use non overlapping memory areas.
Am Freitag, 22. September 2017 13:00:24 UTC+2 schrieb Remus Clearwater: > > From this thread > <https://groups.google.com/forum/#!topic/golang-nuts/KyXR0fDp0HA>, we > know: > > > The GC ignores pointers it knows nothing about. (by Ian) > > So we have this code in cmd/cgo/out.go > <https://github.com/golang/go/blob/57fa1c7c949c5ea1efd756e2ed0c4442998690a9/src/cmd/cgo/out.go#L1450> > : > > func _Cfunc_CString(s string) *_Ctype_char { > p := _cgo_cmalloc(uint64(len(s)+1)) > pp := (*[1<<30]byte)(p) > copy(pp[:], s) > pp[len(s)] = 0 > return (*_Ctype_char)(p) > } > > But what will happend if the go and cgo's malloc overlapped? > (Not meantime, but in a moderated time interval that may happen.) > > Example: > > { > p := C.malloc(uintptr(1024*1024)) // this is C.malloc > pp := (*[1<<30]byte)(p) > doSomething(pp,1024*1024) > } > > { > b:=SomeBigObject{} // go malloc > } > > runtime.GC() > > // this is the 1st GC after the pp being new-ed in go land so far. > // but what will happen if the underlying memory address of pp == b's ? > // the gc might find two totally different go objects which has the > // same underlying memory address. > // what is the gc's behaviour in this circumstance? could this lead > // to some unexpected bugs ? > > Thanks a lot. > > Enjoy! > -- 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.
