On Windows, Mac & Linux there's virtual memory underway for every application software process in a RAM stack.

But in regards to the actual use of my memory accessing data types, where exactly will my memory be mapped to, and when does it become physical:

1.After compilation.

2.During compilation.

3.Upon loader and execution.

I ask because since memory must be protected to avoid overwrites of the kernel, invalid accessing or manipulating, how should I treat memory in my program if I don't know exactly where my memory will really be beforehand, hence, eliminating any abilities to directly keep track of the memory bits in total that my program will use accurately.


The address-space your program sees is ALWAYS virtual. (At least in every modern OS.)
You allocate memory by calling the OS API's for that (or the compiler does it for you when you define variables in your code).
The addresses (or pointers, whatever the programming language calls them) you get returned for this allocated memory are valid in the context of your program.
For memory you allocated yourself, you are responsible for returning it to the OS. If the compiler did things on your behalf the compiler will also have included the necessary cleanup. When your program exits the OS will also do some cleanup.

Where the actual program data resides in the physical RAM of the computer is completely academic. Your OS will map the virtual address space your program sees into the physical RAM and/or swap-space. You yourself simply can't know how that is done at any given time.

It might be important if you are programming a device-driver or a kernel-component, but you obviously don't have the required knowledge about operating systems and programming for that. That much is clear from your question.
Such software operates at a different level and may have to interact with the real physical RAM. There are special methods and API's to deal with that, but you will never encounter those in a normal user-written program.
Another possibility is when you are doing low-level programming on an embedded device where there is no OS to provide this layer of abstraction between virtual and physical RAM. Again: This is something for specialists.

This is simply not something you will ever have to worry about, if you write correct programs by the rules of the programming language.
Of course: If your program is incorrect (e.g. accesses memory it never allocated) the program might crash, or will be terminated by the OS itself, if the OS discovers that the program is misbehaving. Figuring out what went wrong and correcting the problem in the program is an important aspect of programming. It is called debugging.

  • @Keltari Thanks... I thought I corrected all spelling mistakes before submitting, but I missed the most obvious one :-( – Tonny May 22 '13 at 15:41
  • Very ignoeant answer – Dinosaur pawz May 24 '13 at 0:08

This wiki article describes everything you want to know.


  • 2
    You should provide more details in an answer instead of a mere link. – Karan May 22 '13 at 16:45

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.