I was reading the answer of the bigown user regarding overlay and memory management. He cited the page fault that can occur when a program is running. However, this term page fault gave me some doubts.
I was reading the answer of the bigown user regarding overlay and memory management. He cited the page fault that can occur when a program is running. However, this term page fault gave me some doubts.
Page fault is when an application asks to access a memory address and it is not mapped to RAM (it's a bit more complex than this, but let's simplify).
Modern operating systems use a virtual memory system, so you have up to 4GB in 32 bits and theoretically up to 16EB in 64 bits (in practice it is usually more limited.) You can access all this even if you do not have enough RAM. (HDD, SSD, etc.) which is not in use.
The problem is that the application can not directly access something out of RAM. So the operating system needs to load what's on the secondary to the primary (RAM). Most likely laying on top of something that was in use before.
For ease of work this is divided into pages. Usually 4KB each (there are larger pages, but not the case). So when you access an address in the application it's a fake address, it's virtual. There is a translation (the processor does this at the request of the operating system, so it is practically costless) from this address to the actual physical address in memory. This is why moving data can cost quite cheaply since it just needs to change the page table and not actually tinker with memory, much like the disk file table.
For example, an executable can be either loaded into memory or not, depends on the operating system, how much has free memory. It is common for only pages with code to be uploaded. But if you have free memory you can load everything up to serve as a cache. The load may not be made at the time of loading the executable up to optimize its initial load. It depends on a number of factors.
Obviously if you try to access an address that is on a page marked as out of RAM the operating system will have to pick it in the "disk", put in the RAM and only there let the application access. This is the page fault . Failed to access memory directly. Obviously this process is absurdly slower to access RAM directly.
The page may be unavailable at that time by some specific protection.
The page has a trigger when trying to write to it and a copy needs to be done (copy on write).
The page is mapped but needs to be treated for use. To do fast allocations a mapping is done only logically and only when there will be effective use will it be properly prepared.
I did not go into the merits of faults that are faulty and that can not be solved by the operating system, like the (semi) permanent protections.
So it is very difficult to manage memory. This is why GC languages may not be so slow in general use, they help avoid page faults . On the other hand the collections help increase these faults. It's a tricky thing to balance.
The less page faults you have, the faster your application will run. And you can not control it that much. In some languages it is possible to minimize a bit, at least unnecessary faults, but it gives a work and nothing is guaranteed. To minimize even more boatload lots of RAM. And an SSD helps a lot when they occur. It looks like secondary storage will come close to the current RAM speed. This helps, but it's still better not to miss.
Guess what happens if you try to access something that should not, something that can not be mapped? The application crashes, the famous General Protection Failure (GPF) or some more specific protection failure. Or an exception is raised for the application to handle, if at all possible. Do you know why you can hardly see GPF today? Because people use languages that treat it differently or the programmer has learned to handle it in a more cute way.
Many people think this is a bad memory chip, an operating system error, or something, but it's normal.
It is an exception on an internal operating system level.
Open the Task Manager or a better utility such as Process Explorer and monitor the faults. Below is a list of processes with your faults at that time. There are two processes that are increasing by 4 or 5 per second. One of them is FireFox. For privacy I did not copy the columns that can identify anything:
Wanttolearnmore?Windowsshowsyouhowitworksintwo Windows Internals books.