Windows 32位虚拟内存页面映射问题
我正在从这里学习有关 Windows 32 位虚拟内存页面映射的信息
我的目标是现代 Windows 版本，例如 Vista、Win 7、Server 2003/2008 32 位版本。）
（ msdn.com/ericlippert/archive/2009/06/08/out-of-memory-does-not-refer-to-physical-memory.aspx" rel="nofollow noreferrer">http://blogs.msdn.com /ericlippert/archive/2009/06/08/out-of-memory-does-not-refer-to-physical-memory.aspx
两个困惑，
用户空间虚拟内存空间正常限制为2G ，但物理磁盘页存储可能远大于 2G。由于磁盘页面比虚拟内存页面多，因此理论上可以将多个磁盘页面映射到一个虚拟地址页面。如果用户请求访问某个虚拟地址，如果多个磁盘页映射到一个虚拟地址页，那么内存管理器如何知道应该访问哪个磁盘页？
我不知道为什么有像byte[]数组必须使用连续虚拟内存空间这样的限制。我认为理论上即使我们只分配500M的虚拟空间地址，我们也可以重新使用这样的虚拟空间地址来继续映射/取消映射磁盘页面文件来消耗我们想要的数量，甚至大于2G。
有什么想法吗？
I am learning from here about Windows 32-bit virtual memory page mapping,
(I am targeting modern Windows versions, like Vista, Win 7, Server 2003/2008 32-bit versions.)
Two confusions,
user space virtual memory space is limited to 2G normally, but physical disk page storage could be much larger than 2G. Since there are more disk pages than virtual memory pages, so in theory more than one disk pages could be mapped to one virtual address page. If user request to access some virtual address, how did memory manager know which disk page should be accessed if more than one disk pages are mapped to one virtual address page?
I do not know why there is restrictions like byte[] array must use continuous virtual memory space. I think in theory even if we only allocate 500M virtual space address, we can re-use such virtual space address to continue to map/unmap disk page file to consume as much as we want, even larger than 2G.
Any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
字节（或任何其他）数组必须使用连续的地址空间，在本例中为连续的虚拟地址空间。
这是一个可能使碎片成为问题的区域，并且实际上会因内存虚拟化而加剧。由于此类系统中固有的各种“重定向”以及使其高效的性能考虑导致实际分配映射到块（通常是页）中的虚拟地址空间的物理地址空间。
因此，请求 10 字节的虚拟地址空间块实际上可能会导致整个 4K 页面被保留和映射。由于页面内的物理内存必须是连续的，这可能会导致整个 4K 虚拟地址空间被“封锁”。
多个小分配可以放置在一页内（优秀的内存管理器会尝试实现这一点），但实际上保留的地址空间超出了严格要求的范围。考虑在起始 fa 页分配一个字节，然后是 4K - 2 个字节，后面是另一个字节。这（有效地）占据了整个页面。
考虑中间分配是否不再需要，从而被释放。在“顶部”和“尾部”值被释放或移动到其他地方之前，虚拟地址空间中已经创建了一个间隙，该间隙只能由 << 的内容来填充。大小为 4K-1 字节。
如果发生足够多的此类事情，虚拟地址空间中的连续区域的收缩速度将比实际总实际使用内存的收缩速度快得多。
您是正确的，因为没有什么可以阻止您（用户）将您的（仅限 32 位区域）地址空间映射到 CPU/OS 支持的更大的磁盘或内存空间。有些芯片通过 PAE 等机制，使用超过 4GB 的物理地址空间来实现这一点。
Windows 本身提供了一个 API 来处理“更改地址空间映射以在更广泛的池上获得不同的“窗口”（无论是通过 PAE、运行 WoW64、磁盘还是混合）的大多数方面。这称为 AWE。但这样的机制已经存在多年了（正如那些使用传统内存来回忆 EMS 时代的人一样或者确实是分段内存的时代
即使没有CPU和操作系统支持，您仍然可以自己完成。通过各种技术（见下文）手动
处理了 Windows 中的许多更复杂的方面。
byte (or any other) arrays must use contiguous address space, in this case contiguous virtual address space.
This is an area that can make fragmentation becomes an issue, and is actually exacerbated by virtualization of memory. Since the various 'redirections' inherent in a such a system system and the performance considerations in making it efficient lead to actual allocation of physical address space mapped to virtual address space in chunks (commonly pages).
So requesting a 10 byte chunk of virtual address space might actually lead to a whole 4K page being reserved and mapped. Since the physical memory within the page must be contiguous this can lead to a whole 4K of virtual address space being 'blocked off'.
Multiple small allocations can be placed within one page (and good memory managers will try to achieve this) but none the less address space has in effect been reserved over and above what was strictly required. Consider the allocation of a single byte at the start f a page, then 4K - 2 bytes followed by another single byte. This occupies (efficiently) the whole page.
Consider if the middle allocation is no longer necessary, and is thus freed. Until the 'top' and 'tail' values are either freed or moved elsewhere a gap has been created in the virtual address space which can only be filled by something < 4K-1 bytes in size.
If sufficient of these sorts of things occur the contiguous regions in virtual address space shrink much faster than the actual total really used memory does.
You are correct in that there is nothing stopping you, the user, mapping your (limited in 32bit land) address space to the much larger disk or memory space that the CPU/OS supports . Some chips make this possible with more than 4GB of physical address space via mechanisms like PAE.
Windows itself provides an API to deal with most aspects of 'changing the mapping of your address space to get a different 'window' onto a wider pool (be it via things like PAE, running WoW64, disk or a mixture). This is called AWE. But mechanisms like this have existed for years (as those who remember the days of EMS with conventional memory or indeed the days of segmented memory.
Even without CPU and OS support you can still do it yourself by hand by a variety of techniques (see below).
A great deal of the more complex aspects of this in windows were dealt with by ever interesting Raymond Chen.
（某些版本的 Windows 有一个开关可以为用户程序启用 3G，但出于本次讨论的目的，我们将忽略它，因为原理是相同的。）
32 位程序只能访问 4G 内存，因为这是最大的内存指针可以容纳 32 位。程序运行时，有的内存空间被映射到自身，有的被映射到操作系统。否则，当您调用操作系统时，操作系统代码无法同时看到自己的内存和程序内存。
因此，您的程序无法获得全部内存，因此连续分配受到限制。
现在，不同的程序可以拥有所有可寻址内存的不同子集。一些 32 位芯片允许物理上超过 4G 的内存，但是，任何给定的进程，因为它是 32 位的，一次只能直接“看到”最多 32 位或 4G，其中一些属于该进程（2G ），还有一些交给操作系统（2G）用于管理程序和其他程序。
这是我能给出的最简单的解释；请参阅虚拟内存了解更多内容技术解释。
(There is a switch for some versions of Windows to enable 3G for user programs, but we'll ignore that for purposes of this discussion, since the principle is the same.)
32bit programs can only access 4G of memory, since that's the largest pointer you can fit in 32 bits. When a program runs, some of the memory space is mapped to itself, and some is mapped into the operating system. Otherwise, when you call into the operating system, the operating system code couldn't see both its own memory and the program memory at the same time.
So your program doesn't get all of the memory, and hence the restrictions on contiguous allocation.
Now, different programs can have different subsets of all of the addressable memory. Some 32bit chips allow physically more than 4G of memory, but still, any given process, since it's 32bits, can only "see" directly up to 32bits-worth, or 4G, at a time, some of which belongs to the process (2G), and some to the operating system (2G) for managing the program and other programs.
That's as simple an explanation as I can give; see Virtual Memory for a longer and more technical explanation.
Mark Russinovich 写了一篇好文章 突破 Windows 的限制：虚拟内存< /a>.我认为您应该阅读它以清楚地了解它是如何工作的。
Mark Russinovich wrote good article Pushing the Limits of Windows: Virtual Memory. I think you should read it to clearly understand how it is works.
进程可用的总虚拟地址空间为 4GB。其中上面的 2GB 对于所有进程都是通用的，并且只能由系统级组件访问。较低的 2GB 是每个进程私有的，不共享。这与 RAM 的大小完全无关。映射到用户进程的磁盘页面可能远远超过 2GB。由于 2GB 进程空间是私有的，因此所有进程的总地址空间将远远超过 2GB。即使在理论上，将多个磁盘页面映射到同一进程中的一个虚拟地址也是不可能的。
The total virtual address space available to a process is 4GB. The upper 2GB of this is common to all processes and is accessible only to system level components. The lower 2GB is private to each process, it is not shared. This has absolutely nothing to do with the size of RAM. There can be far more than 2GB of disk pages mapped to user processes. Since the 2GB process space is private the total address space for all processes will be far more than 2GB. It is impossible, even in theory, for more than one disk page to be mapped to one virtual address in the same process.