连续的内存块和VM
我正在阅读有关虚拟内存的内容，据我了解，每个进程都有自己的虚拟机表，该表将虚拟机地址映射到实际内存中的物理地址。因此，如果一个进程连续分配对象，它们可能会存储在物理内存中完全不同的位置。我的问题是，如果我分配和数组应该存储在连续的内存块中，并且如果数组的大小需要比一页可以提供的空间更多的空间，据我所知，数组将连续存储在VM中但可能在 PM 中完全不同的位置。这是正确的吗？如果我误解了 VM 的工作原理，请纠正我。如果它是正确的，是否意味着我们只关心虚拟机中的分配是否连续？
I was reading up on Virtual Memory and from what I understand is that each process has its own VM table that maps VM addresses to Physical Addresses in real memory. So if a process allocated objects continuously they can potentially be stored in completely different places in Physical Memory. My question is that if I allocate and array which is supposed to be stored in a contiguous block of memory and if the size of the array requires more space than one page can provide, from what I understand is that array will be stored contiguously in VM but possibly in completely different location in PM. Is this correct? please correct me if I misunderstood how VM works. And if it is correct does that mean we are only concerned whether allocation is contiguous in VM?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
现代内存处理程序永远无法真正了解与页面边界重叠的内容在物理内存中是否实际上是连续的。内存胶合逻辑本质上将所有可寻址内存页视为无序集合，并且排序本质上与进程相关联；不能保证对于最终被分配相同的两个物理内存页（在不同时间点）的不同进程，这些物理页之间的表达关系将是相同的。实际上，CPU 和内存之间有一个处理这些内容的转换层。
Whether or not something that overlaps a page boundary is actually contiguous in Physical Memory is never really knowable with modern memory handlers. Memory glue logic essentially treats all addressable memory pages as an unordered set, and the ordering is essentially associated with a process; there's no guarantee that for different processes that end up getting assigned the same two physical memory pages (at different points in time) that the expressed relationship between those physical pages will be the same. Effectively, there's a translation layer between the CPU and the memory that handles this stuff.
这是正确的。对于您的应用程序来说，数组必须看起来是连续的，但在物理上可能分散在内存中。
That's right. Arrays must only looks contiguous for your application, but may be physically scattered on memory.
我只是想补充/明确一点，从用户空间程序的角度来看，分配的内存块总是出现连续的。操作系统与 CPU 的内存管理单元 (MMU) 一起处理所有虚拟内存到物理内存的映射，程序员永远不需要担心如何处理这种映射（当然，除非所述程序员是编写操作系统）。
编译器（或用汇编语言编写代码的编译器）可以将程序的地址视为从 0 开始，直到该特定程序所需的最大地址。然后，操作系统为每个进程创建一个页表，并使用该表来部分解码每个虚拟内存位置的物理地址。操作系统将程序中的地址视为两个独立的部分，即页面地址和该页面的偏移量。然后，MMU将页地址转换为物理帧地址。请注意，从操作系统的角度来看，物理内存“帧”类似于概念上的“页”。这两个大小相同（例如 4096 字节）。
由于物理内存被划分为大小相等的帧，并且页面大小与帧大小相同，因此您可以知道有多少虚拟地址用作页面位置以及该页面的偏移量有多少。例如，如果您的操作系统为每个进程“分配”4 GB（如 Linux 中的情况），并且您的页面/帧大小为 4096 字节，则您可以知道 20 位（4,294,967,296 字节 / 4096 字节 = 2 ^ 20 = 32位地址的1,048,576页/页地址）被用作页地址，然后将其转换为由MMU确定物理帧地址，剩下的12位作为偏移量来确定从页/帧开头开始的地址位置。
VM（用户空间）地址 -->页+偏移量(OS) -->帧 + 偏移量 (MMU) = 物理地址
I just wanted to add/make it clear that from a user space program's point of view, a chunk of allocated memory always appears contiguous. The operating system in conjunction with the CPU's Memory Management Unit (MMU) handles all virtual to physical memory mappings and the programmer never needs to worry about how this mapping is handled (unless, of course, said programmer is writing an operating system).
A compiler (or one who writes code in assembly) can treat a program's addresses as starting from 0 and going up until the largest address needed for that particular program. The operating system then creates a page table for each process and uses this table to partially decode a physical address for each virtual memory location. The OS treats an address in a program as two separate parts, the page address and the offset into that page. Then, the MMU translates a page address into a physical frame address. Note that a physical memory "frame" is analogous to the conceptual "page" from the standpoint of the OS; these two are of the same size (eg 4096 bytes).
Since physical memory is divided into equally sized frames, and page size is the same as frame size you can know how much of your virtual address is used as a page location and how much is an offset into that page. For instance, if your OS "allocates" 4 gigabytes to each process (as is the case in Linux), and your page/frame size is 4096 bytes, you can know that 20 bits (4,294,967,296 bytes / 4096 bytes = 2 ^ 20 = 1,048,576 pages/page addresses) of a 32 bit address are used as a page address, which will then be converted to a physical frame address by the MMU, and the remaining 12 bits are used as an offset to determine the location of the address starting from the beginning of the page/frame.
VM (user pace) address --> page + offset (OS) --> frame + offset (MMU) = physical address