我正在将(由我)为 Windows 编写的项目移植到移动平台。
我需要 VirtualAlloc (+friends) 的等价物，自然是 mmap。但是，有 2 个显着差异。
VirtualAlloc返回的地址保证是所谓的分配粒度 (dwAllocationGranularity) 的倍数。不要与页面大小混淆，这个数字是任意的，在大多数 Windows 系统上是 64K。相比之下，mmap返回的地址只能保证页面对齐。可以通过调用
VirtualFree立即释放保留/分配区域，无需传递分配大小(即VirtualAlloc 中使用的大小))。相比之下，应该为munmap指定要取消映射的确切区域大小，即它释放给定数量的内存页面，而与它们的分配方式无关。
这给我带来了问题。虽然我可以接受 (2)，但 (1) 是一个真正的问题。我不想深入细节，但假设更小的分配粒度(例如 4K)将导致严重的效率下降。这与我的代码需要在分配区域内的每个粒度边界处放置一些信息有关，这会在连续的内存区域内强加“间隙”。
我需要解决这个问题。我可以考虑分配增加区域的非常天真的方法，以便它们可以 64K 对齐并且仍然具有足够的大小。或者保留大量的虚拟地址空间区域，然后分配正确对齐的内存区域(即实现一种对齐的堆)。但我想知道是否有其他选择。例如特殊的 API，可能是一些标志、 secret 系统调用或其他任何东西。
最佳答案
(1)其实很容易解决。如您所见，munmap 采用大小参数，这是因为 munmap 能够部分 释放。因此，您可以分配一 block 比您需要的更大的内存，然后释放未对齐的部分。
关于c++ - mmap : enforce 64K alignment，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31411730/