运行 32 位编译二进制文件的进程可以使用超过 4GB 的内存吗？
在 Snow Leopard（64 位机器）中运行 32 位编译版本的 python 的单个进程是否有可能出现消耗 > top 命令看到的虚拟内存是 4GB（比如说 5.4GB）？
我执行了 file ...python 来查看该二进制文件不是 x86，但它似乎消耗了超过 5GB 的内存。
我的猜测是，使用的库（RPy）正在“mmap”数据块，并且内存中的缓存出现在我的进程的内存占用空间下。
或者也许我还没有验证 Python 二进制文件是 32 位的。或者可能存在一些 32 位/64 位混合（libffi？）。
完全困惑了。
Is it possible for a single process running a 32-bit compiled version of python in Snow Leopard (64-bit machine) to appear to consume > 4GB (say 5.4GB) of virtual memory as seen by the top command?
I did a file ...python to see that the binary was not x86, yet it appeared to be consuming over 5GB of memory.
My guess is that the libraries that were used (RPy) were 'mmap'ing chunks of data, and the in-memory cache was appearing under the memory footprint of my process.
Or maybe I haven't verified that the Python binaries were 32-bit. Or maybe there's some 32-bit/64-bit commingling going (libffi?).
Totally confused.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不，这在物理上是不可能的。这并不能阻止操作系统由于对齐和碎片而分配超出其可以使用的空间，例如，它可能拥有整个页面，但实际上并未映射到所有页面。然而，任何进程实际使用超过 4GB 的空间都是不可能的，而且很可能大大小于内核空间的大小。
No, it's physically impossible. That doesn't stop the OS assigning more than it can use due to alignment and fragmentation, say, it could have a whole page and not actually map in all of it. However it's impossible to actually use over 4GB for any process, and most likely substantially less than that for kernel space.
如果进程使用某种疯狂的长/远/扩展指针并根据需要将数据映射到 32 位地址空间或从 32 位地址空间映射出数据，则这是可能，但在这一点上它几乎不符合反正32位的。 （Python 绝对不会这样做，所以 @DeadMG 的答案几乎肯定是实际发生的情况。）
It is possible if the processes is using some kind of insane long/far/extended pointers and mapping data into and outof a 32-bit address space as it needs it, but at that point it hardly qualifies as 32-bit anyway. (Python most definitely does not do this, so @DeadMG's answer is almost certainly what is actually happening.)