简体   繁体   中英

From where does the program allocate memory?

As a C and C++ programmer I have used malloc and new to allocate memory. I am just wondering: how does the OS allocate memory?

  1. Does it allocate from RAM or from hard-disk or from somewhere else?

  2. Can I borrow memory from hard disk just in case?

It's actually much more complicated than you'd think. The OS thinks of everything in "pages", it splits the RAM into pages, and the hard drive into pages. When your program starts, it checks how much memory your executable takes, chooses some RAM pages for it, and assigns those pages to your program. If there's no "usable" pages in RAM, it takes older some pages in RAM, and saves them to the hard drive somewhere tucked away, and then gives those pages to you.

When you allocate memory in your program, the memory manager of your program will try to find a free spot in the pages the operating system has assigned to it. If there's not enough, it asks the operating system for more pages, and the operating system makes more room and gives your application more pages.

If your program has a page that it hasn't used in a while, (even code sometimes), the operating system may save that page to the hard drive, and when your program tries to use that page again, the operating system pauses your program, reloads the page into RAM, and then resumes your program.

Here's a diagram that makes no sense

C++ addresses           RAM         hard drive
+------------+    +------------+  +------------+  
| 0x00010000 |\ ->| 0x00010000 |  | 0x00010000 | 
+------------+ X  +------------+  +------------+
| 0x00020000 |/ ->| 0x00020000 |  | 0x00020000 |
+------------+    +------------+  +------------+
| 0x00030000 |-->?         /----->| 0x00030000 |
+------------+            /       +------------+
| 0x00040000 |-----------/        | 0x00040000 |
+------------+
|    etc     |

So in this code, your code has stack memory of 0x00010000-0x0002FFFF, and you've allocated some dynamic memory, and that's in 0x0004000. AS FAR AS YOU KNOW! In reality, when you access 0x0002000, the operating system says "oh, I've stored that page of yours in the RAM address 0x00010000" and reads those values for you. You haven't touched the page of 0x00040000 in a while, so the operating system saved it to the harddrive at harddrive location 0x00030000, but will bring it into RAM if you try to use it. The operating system hasn't given you the address 0x00030000 yet, so if you try to use it, the operating system will tell you that address doesn't have any actual pages, and you get a segmentation fault (segfault). What makes this interesting is when you ask for a large contiguous chunk like a vector, the operating system can give you any old pages it finds laying around, it doesn't have to worry if they're contiguous or not. They look contiguous to your program, which is all that matters.

This also allows the operating system to hide memory of one program from another, which keeps them from being able to read or modify other program's memory space. They're safe! Except... there are ways to tell the operating system to share a page between two programs (though they may have different addresses in each program), allowing them to share pages. DLLs do this.

In reality, it's far more complicated than this.

1) Does it allocates from RAM or from hard-disk or from somewhere else?

On modern systems/platforms supporting virtual memory, the operating system decides where and how to allocate/store the memory. The system is also free to move the memory from one place to another either in ram or on disk.

2) Can I borrow memory form hard disk just in case ?

The operating system that manages memory can borrow memory from disk.

You can also explicitly borrow memory from disk by storing data in a file. C and C++ standard libraries ( stdio.h and fstream ) enable files manipulation.

When you address memory allocated by malloc or operator new , it is in RAM and has a unique address. It's the operating system's job to have that block of memory in RAM when addressed, but it might swap it out to disk at its discretion. Since swapping is slow, it's up to the OS to figure out how to minimize the swapping.

Operating systems that use "virtual memory" allow you to set how much of your disk space is available to the virtual memory manager.

There is no need for you to try to manage this yourself, although you might consider whether it is better to use a database to manage the data, especially if the lifetime of the data is longer than a single session.

This answer is going to be pretty Linux-centric

It's a lot more complicated than it seems. When you allocate a block of memory, one of two things might happen. If your process already has enough memory that was previously freed but not returned to the OS (allocators usually don't), that memory will be marked as allocated in the allocators tables, and will be returned. When the process doesn't already have the memory, the allocator asks the OS for more. On Linux, that means the brk or sbrk syscalls. I don't know what it means on Windows or OSX.

All modern, common OSes (Linux, Windows, OSX, and their derivatives) use virtual memory, the concept of addresses not necessarily pointing at real RAM. Until you put something in it, the memory you allocated might not exist at all. Once you start using it, the OS needs to make room for it in RAM. To do this, the OS will store other, unused pages (parts of memory) in a swap file or partition on the disk, if it is so configured.

The OS is constantly moving pages of memory in and out between swap storage and actual RAM. Whenever your process accesses a part of memory that isn't in RAM right now, the processor generates a page fault, which causes the OS to load that page(s) from the disk, and make room in memory for them by moving other pages into swap.


So basically, in a modern OS, memory can come from anywhere the OS chooses, and might not even exist when you've allocated it .


Note: Some OSes, like Linux most of the time, will even let you allocate memory that it doesn't have to give you. This is called overcommiting memory.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM