监视器未显示正确的内存使用情况

Question

I want to know how I can use the resource monitor, any kind, htop top , etc. to track the memory usage of a processes. Let's write a simple C program.

int main() {
    while(1){}
    return 0;
}

After the compilation, the executable output a.out is only 16Kb

$ ls -lah ./a.out                                                                                                                                           [8:43:44]
-rwxr-xr-x  1 user  staff    16K May 17 08:43 ./a.out

As I understood, the code has no variable, no malloc and all kinds of statement that requires any additional memory usage other than the code itself, which will be loaded to the memory when running. Some additional memory for stack pointer, frame pointer, etc. is expected but shouldn't be too much.

Interestingly, when I run the code. The System Monitor gives a very different opinion.

So I am using MacOS, the monitor states that the Virtual Memory usage is 30Gb+ !

Okey?! Maybe this is due to some optimization, or some unique technique that MacOS manages memory. Let's try running that in a Ubuntu Virtual Machine with 1Gb memory.

I know this looks more reasonable than 30Gb, but 2356Kb?

Am I looking at the wrong indicator?

Answer 1

As I understood, the code has no variable, no malloc and all kinds of statement that requires any additional memory usage other than the code itself, which will be loaded to the memory when running.

Your code doesn't have much; but your code is typically linked with some startup code that does things like preprocess command line arguments, initialize parts of the C library, and call your main() .

You'll also have a stack (eg so that the startup code can call your main() ) that consumes memory (whether you use it or not).

When your program is started the executable loader will also "load" (map into your virtual address space) any shared libraries (eg C standard library, that's likely needed by the startup code you didn't write, even if you don't use it yourself).

The other thing that can happen is that when the startup code initializes the C standard library, the C standard library can initialize the heap (for things like malloc() ), and something (the rest of C standard library initialization, the remainder of the startup code) could use malloc() even though the code you didn't write doesn't use it.

Of course operating systems/virtual memory management uses pages; so the size of each of your program's sections ( .text , .data , etc), each section in each shared library, your stack, your heap, etc; are rounded up to the page size. Depending on which computer it is, page size might be 4 KiB (16 KiB for recent ARM/M1 Apple machines); and if the startup code you didn't create wants 1 byte in the .data section it costs 4 KiB (or 16 KiB) of memory.

So I am using MacOS, the monitor states that the Virtual Memory usage is 30Gb+!

I'd guess that most of it is space that was allocated for heap; where a tiny amount of the space is used and most isn't. If you assume that there's 176 KiB of private memory (used by your program and its startup code) and 440 KiB of shared memory (used by shared libraries), and assume that "32.54 GiB" is 3412000000 KiB; then maybe it's "3412000000 - (176 + 440) = 3411999384 KiB of space that was allocated but isn't actually being used".

I know this looks more reasonable than 30Gb, but 2356Kb?

Continuing the assumption that it's mostly "allocated but not used" heap space; it's good to understand how heap works. "Allocated but not used" space costs almost nothing, but asking the OS to allocate space (eg because the program actually used it all and ran out of "allocated but not used" space) involves some overhead. For this reason the C library tends to ask the OS for large pieces of "allocated but not used" space (to minimize the overhead by reducing the chance of needing to ask the OS for more space) and then splits it into tiny pieces when you call malloc() .

With this in mind; and not forgetting that the startup code and libraries are "generic" and not likely to by optimized specifically for any one program; you can say that the best size for the heap's "allocated but not used" space is impossible to determine, but ranges from "maybe too small but it doesn't matter much" to "maybe too big but nobody cares". Different compilers and/or libraries and/or operating systems make different decisions; so the amount of "allocated but not used" space varies.

Am I looking at the wrong indicator?

I don't know (it depends on why you're looking at memory stats to begin with).

On modern machines the total virtual address space may be 131072 GiB (where most is "not allocated"), so if you're worried that "allocated but not used" space is going to cause you to run out of "not allocated" space later then you're looking at the right indicator.

Typically people care more about (some subset of) "allocated and actually used space" though.

If you're worried about consuming too much actual RAM (eg worried about increasing the chance that swap space will be used by the OS, which could reduce performance of all software and not just yours) then you'd want to look at the "Real Memory Size"; but I suspect that this includes shared memory (which would be used by many programs and not just your program).