用户空间中的虚拟内存地址范围

Question

在Linux中，用户空间中虚拟内存地址的范围（即malloc返回的值的范围）与整个64位虚拟内存空间相同吗？ 或者，是否有保证不能在用户空间中看到的64位虚拟内存空间的任何子范围？

欢迎回答UNIX系统或Windows系统。

当然，我不打算将这种错误代码引入某些产品中。 我只是想象，如果有一个备用空间，我们可以使用该空间来存储flgas，例如is_constructed标志用于延迟构造，并且可以节省很多空间。 通常，即使我们仅使用1bit，也需要1byte（堆栈）分配。 此外，将这种值编码到内存地址中可能会导致错误的内存预取或分支错误预测。 然后，我要检查节省内存带宽和CPU错误预测中哪个较大。

Answer 1

虚拟地址的可能范围取决于 处理器和内核以及ABI 。 但是我强烈建议您不要编码一些与地址和指针中的某些位有关的技巧（因为您的代码可能在某些处理器上有效，而在其他处理器上则无效）。

如今 ， 某些 ^* x86-64处理器显然只使用了48位虚拟地址空间，但我不建议在您的代码中使用该知识（几年内或某些高端型号可能会出错）。 另请参见x86-64 ABI 。

^{如果指针超出48位范围，则会出现页面错误，即SIGSEGV，处理器不会忽略未实现的位。 因此，指针或地址的高位应全为零或全为1。}

在Linux上，您可以使用cat /proc/self/maps和cat /proc/$$/maps以获得更多线索。

顺便说一句，在Linux上，您可以使用带有MAP_ANONYMOUS | MAP_NORESERVE mmap（2）进行MAP_ANONYMOUS | MAP_NORESERVE MAP_ANONYMOUS | MAP_NORESERVE ，一些较大的地址范围（以及以后在其中调用带有MAP_FIXED mmap ，或者从不使用它）以避免它稍后被您的进程使用（或者，如damon所评论的那样，使用特定于x86-64的MAP_32BITS ）可能比将地址位限制为48位更为明智。

另外，在Linux上捕获SIGSEGV 棘手 （您将需要一些处理器特定的代码）且成本很高。 也许您需要某种外部寻呼机机制 （在GNU Hurd上存在，但在Linux上不存在）。 或者mmap在某些FUSE文件系统上添加一些伪文件。

注意：大多数x86-64处理器只有48位地址，但是我不建议使用该地址。

注2：处理器制造商记得IBM / 360所做的事情：忽略了高地址位（最初为24位）。 当IBM必须将地址扩展到31位时，这对于软件行业来说是一场噩梦。 因此，硬件制造商了解了这一教训，并禁止今天（在硬件中）对未使用的地址位进行顽皮的欺骗。