On Fri, 22 Sep 2017 16:58:53 -0700 (PDT)
Remus Clearwater wrote:
> So, if the reservation scheme breaks down
Then OS will not even boot.
https://www.google.com/search?q=OS+memory+management+lecture
--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE
--
You received this message because you are su
On Fri, Sep 22, 2017 at 4:58 PM, Remus Clearwater
wrote:
>> 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 t
> 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
> tr
On Fri, Sep 22, 2017 at 6:54 AM, Remus Clearwater
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
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?
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. Septem
