
Go Memory Management - ngaut
https://povilasv.me/go-memory-management/
======
TheDong
Spoilers for why the simpler program is different: It doesn't do networking,
which means it doesn't use any cgo. The networking stack by default links
against libc, but if you don't use it, your go program doesn't have to link
against libc.

You can always configure the CGO_ENABLED or -tags netgo flag in order to cause
networking to not use libc either.

~~~
z92
And I thought libc didn't use more than a few megs of ram. Here the difference
seems to be like hundreds of megs.

~~~
Arkanosis
It's virtual memory, not physical memory. One should really see virtual memory
as “addresses available for use within a single process”, not “space to store
actual data, shared by all processes on a computer”.

On modern 64 bits architectures, you have plenty of it to spend. To give an
idea of how much of it you have: since Linux 2.6.11 on x86_64, one can address
up to 128 TiB (that's 128 _thousands_ of GiB) of virtual memory _per process_.
Starting with Linux 4.12, one can address up to 128 PiB (that's 128 _millions_
of GiB) of virtual memory per process. That's completely unrelated with how
much physical memory you have.

~~~
scott_s
Correct. When explaining it to students, I have used the metaphor of a housing
developer building homes in a subdivision: going to the OS to "allocate"
virtual memory is like getting a building permit from the government for a
large swath of land. Having permission to build is not the same as a house
actually being on that land (which is analogous to physical memory).

Much as housing developers are incentivized to get permits for a large block
of land at a time, general purpose memory allocators are incentivized to ask
the OS for permission to use large blocks of virtual memory at a time. Asking
the OS for virtual memory is very slow, so to avoid doing it a lot, general
purpose memory allocators ask for big chunks and manage those chunks
themselves.

------
zahreeley
Very good explanation of memory management

