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.
Ps:
-- more detailed description of the malloc may "overlapped":
// C.malloc
// new big mem chunk
mmap() -> addr0
// go has a object reference to `addr0`
// C.free
munmap(addr0)
// go malloc
mmap() -> addr0
// go has a second object reference to `addr0`
// -> "overlapped"
{
p := C.malloc(uintptr(1024*1024)) // this is C.malloc
pp := (*[1<<30]byte)(p)
doSomething(pp,1024*1024)
// may be better to write this even it could be done in `doSomething`
C.free(p)
}
{
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 ?
On Friday, September 22, 2017 at 8:13:05 PM UTC+8, Gernot Reisinger wrote:
>
>
> 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.
