物理内存与虚拟内存

Question

I know that when a new process is created there will be a virtual address space that is associated with that process .That virtual address space is located in the virtual memory pages and mapped into memory pages inside the physical memory in a non-contiguous way.

My question is :

When a thread will store a value or allocate space for a variable , it will be stored/allocated in the virtual memory , but are those changes written in the same time to physical memory ?

Answer 1

In short, yes.

In order for you to be able to read or write to memory, the virtual address must be mapped to physical memory. So writes to your variable will always be backed by physical memory (there may be a delay due to caching, but that has nothing to do with physical vs virtual). If the memory isn't currently mapped when you do the write, then a page fault occurs which will allow the OS to step in and map the physical memory.

If it needed to map the memory in, it can come from the "standby" list, which means that the memory was already in physical memory and the OS just needed to hook it up (a soft fault ). Or it may have to read the memory from disk (aka a hard fault ); which can come from the pagefile, a memory mapped file, or contents of a binary file.

Edit - Clarification on Memory Lists and Page Faults:

Zero List These are pages of physical memory that are free and have been zeroed out. When an application allocates more memory, the OS first pulls from this pool of memory (if available). Mapping these into a processes' address space is a soft fault.

Free List These are pages of physical memory which the OS is in the process of scrubbing and is about to stick onto the Zero list.

Standby List Windows will periodically unmap memory from your virtual memory on the off chance that someone else may need more memory. Conversely, if there is bunch of memory in the Zero List, it will find pages of memory which your application is likely to need again and pre-load it into memory. All of these pages are stored in the Standby list. They are not assigned to any one application and are liable to be scrubbed and re-assigned if there is an application which has a sudden need for more memory.

Run perfmon.exe /res and click on the "Memory" tab to see how much is associated with the various Lists. You will often observe that Windows likes to keep a fair amount of memory in the Standby list.

Soft Fault If your application allocates memory or reads or writes to memory which the OS stole or pre-loaded (and placed on the standby list), then it is a very simple thing for the OS to assign back to your process. Soft faults are cheap.

Hard Fault If the memory you need is not anywhere in physical memory, then a hard fault is encountered, and the OS needs to "page" it in from some type of storage device. This is typically slow and are what developers may be concerned about when performance tuning.

To answer your comment
Allocating memory typically results in soft faults as the OS pulls from the Zero List and then steals from the Standby list to fulfill the request. Nothing needed to be read from any physical media so, no hard faults were encountered.

Once you've allocated the memory, the OS may later push that memory out to the Standby List. If you reference it again, then there is a soft fault to put it back into your address space. If someone else needed the memory, then the OS can flush that memory to the page file (writing the data out is not a "fault"). Once you then reference that memory address again, a hard fault occurs and the page is read and mapped back into your address space.

Answer 2

There is no virtual memory separate from physical memory. All reads and writes to memory must go to physical memory.

Here is how virtual memory typically works in hardware:

• When a load or store instruction is executed, the processor first calculates the address in the virtual memory address space. (This often involves adding together the contents of processor registers and/or values encoded into the instruction itself.)
• Then the processor looks up the virtual address in tables it has. These are tables that describe the translation from virtual memory to physical memory.
• If the processor finds a match for the virtual address, it uses data in the matching table entry to change the virtual address into a physical address. (Usually, the high bits of a virtual address are a key to the table and the low bits are an offset within a page. To form the physical address, new high bits are taken from the table entry, and the same low bits are used.)
• Then the processor performs the load or store operation using the calculated physical address.

If a virtual address is not found in the tables the processor has in its special registers, then one of several things may happen:

• Some processor models search special tables in memory (which are created and maintained by the operating system) for additional information about maps from virtual memory to physical memory.
• If the processor cannot do the above or does do a search but fails to find a match, it generates an exception. An exception stops the current program, makes some special changes inside the processor, and starts executing part of the operating system instead of the user program.
• The operating system examines the cause of the exception and decides what to do.

The operating system typically does one of several things:

• If the reason for the exception is just that the processor did not have the appropriate table entries for the particular address the process tried to access, but that address is part of the process' virtual address space as established by the operating system, then the operating system loads the appropriate data into the processor and resumes execution of the process.
• If the user process tried to access memory that was in its virtual address space but currently did not have a physical address, then the operating system allocates new physical memory for the process, sets up the tables to describe the new map from that part of virtual address space to the allocated physical memory, and resumes execution of the user process. (This allocation of new physical memory might involve deallocating other physical memory. Sometimes that can be done simply by unmapping pages that have not been used in a while and erasing their contents [for security]. Sometimes it requires writing the contents of pages to disk, to save them for later when they are needed again.)
• If the user process tried to access memory that was not in its virtual address space (of course, the numbers are in the space, but there might have been no allocation of virtual memory to that portion of the address space), then the system sends the process a signal, causing it to execute a signal handler for the error. If the process has no signal handler for this problem, the operating system will terminate the process.