I'm wondering about how operating systems let child processes know how much available memory there is.

Say the whole computer has 1GB RAM memory built in. The operating runs and uses 100MB (I have no idea how much an operating system actually uses). So there is 900MB left.

Then you run 10 programs. Each program creates 10 child processes. The question is, what these parent and child processes see as the total memory available to them.

As a second part to the question to make it a little more complex, say that the applications have been running for a while and now there is 500MB available on the computer (say the operating system used 100MB more, and the applications used 300MB more, to get to this level of 500MB left). The question now is what these parent and child processes see as the available memory at this point. If it's the same as before, or different, and how it is different.

The reason for the question is because I've read about Virtual Memory which states:

virtual memory [is a] technique that provides an "idealized abstraction of the storage resources that are actually available on a given machine" which "creates the illusion to users of a very large (main) memory."

So basically, it sounds like each process in case (1) will get told either "you have 1GB available memory", or "you have 900MB of available memory". I am not sure what it would actually say, if it says the total on the whole computer, or the total - the operating system's usage.

Then for case (2), it would read either "1GB available", "900MB available", "600MB available", or "500MB available". Same situation, I'm not sure what it would say.

It could also be different from those values. The operating system could somehow approximate the available memory for each of the 100 child process, dividing it evenly perhaps. So if there is 500MB left on the computer, that would mean each process would be told "you have 500 / 100 == 5MB of available space". But then if this is the case, if one process used up 5MB, and there was still 495MB left, wondering if it would be allowed to start using this, and get told a new number of what is available. This is why I don't think this is how it's typically done, and rather it seems the OS would tell probably what is available on the computer as a whole (so 1GB).

Also, the reason why I think it would always say "1GB" is because I am not sure if there is a way to determine how much memory a single process is using (or if the operating system knows how much memory it is using). If the OS does know how much it itself is using, then it seems like it would report 900MB.

Another piece of the confusion is that, if the memory usage is constantly changing, and the OS tells each process what is the total memory - the used memory, then you would have to constantly check how much memory is available if you were to try accessing more memory. That is, you couldn't cache the memory usage when the program starts. It could be that the program, sitting idle for a few hours, starts with 100MB of memory "on the computer", but then after that while it checks again to find "oh wait there is only 5MB available". For some reason that seems like undesirable behavior, but I'm not sure.

Any help on understanding generally how an OS tells the child processes how much available memory there is at different points of time would be helpful. Thank you.

  • The OS would only report virtual memory sizes for any "memory" reports to a process, since physical memory is not directly accessible. – sawdust Aug 22 '18 at 3:47

The OS doesn't "tell" the program anything about free memory.

Every program operates in its own virtual memory area where it has access to (What it sees as) the entire potential memory address space allowable. For a 32-bit process what it knows as "the memory" is the entire 4GB of addressable memory, for 64-bit the space is much larger. The process can allocate memory from that area which then tells the operating system that it needs to back areas of that address space with physical memory so that it can be read from and written to, but the program has (in theory) as much memory as it wants.

On a system with only 1GB of RAM this means that when physical memory is full the operating system then starts pushing data out to the swap file or partition. This is done without the involvement of the actual process whose memory is being paged out. If the process tries to access the paged out memory then the operating system halts the process, pulls the data back in from disk and resumes the process.

A program can query how much physical RAM is free, so that they can limit themselves in low memory situations, but they are not artificially limited by the operating system unless it runs out of physical RAM and swap space in which case the program will simply get an error when attempting to allocate memory.


One of the great things about running on a modern OS is that applications have no need to know how much RAM is in the system or how much is available. In fact, most applications are in blissful ignorance of RAM details, how many cores the CPU has, the size and number of physical drives, whether the computer is connected to a network or the Internet, and much more. This is as it should be. The OS was designed to be used this way.

The OS provides to applications a standard virtualized environment that is independent of the hardware. Instead of directly accessing RAM, applications access only a virtual address space that is independent of RAM size. To an application, that is what memory is. RAM is just a performance optimization (with current technology a necessary one) and an implementation detail. Parts of the applications code and data will be in RAM, the pagefile, or in the original files. This can change according to the needs of the application and resource availability. These details are managed by the OS and is invisible to the application which couldn't find out even if it wanted to.

For applications that need this information, hardware details can be requested from the OS but few do. For the most part only system utilities need this information. Most applications have as little need for this as the average driver needs to know about ignition timing or fuel mixtures.

All of this is for the good. It means application developers can devote their time to the requirements of the application without having to deal with the messy details of the hardware on which it is running. That is what the OS is for. It means a properly written application designed for Windows 95 with 4 MB RAM can run on a modern Windows 10 system with many GB of RAM. And the application operates the same and is unaware of the difference. Not all applications are that well written. Of course the modern system will perform better and provide many more capabilities to the user but the application knows nothing of that.

This means a great deal of work for OS designers and developers but many millions of users reap the benefits.

  • This all makes sense. Regarding "Most applications have as little need for this as the average driver needs to know about ignition timing or fuel mixtures." I am thinking in terms of how a debugger works, such as an debugging an operating system. – user39251 Aug 22 '18 at 17:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy