我正在将（由我）为 Windows 编写的项目移植到移动平台。
我需要一个相当于VirtualAlloc(+friends) 的，自然是mmap. 但是，有 2 个显着差异。
返回的地址VirtualAlloc保证是所谓的分配粒度( dwAllocationGranularity) 的倍数。不要与页面大小混淆，这个数字是任意的，在大多数 Windows 系统上是 64K。相比之下，返回的地址mmap只能保证页面对齐。
可以通过调用 立即释放保留/分配的区域VirtualFree，并且不需要传递分配大小（即 中使用的大小VirtualAlloc）。相反，munmap应该给出要取消映射的确切区域大小，即它释放给定数量的内存页，而与它们如何分配没有任何关系。
这给我带来了问题。虽然我可以忍受 (2)，但 (1) 是一个真正的问题。我不想深入细节，但假设更小的分配粒度，例如 4K，将导致严重的效率下降。这与我的代码需要在分配区域内的每个粒度边界处放置一些信息的事实有关，这会在连续内存区域内施加“间隙”。
我需要解决这个问题。我可以考虑分配增加的区域的非常幼稚的方法，以便它们可以 64K 对齐并且仍然具有足够的大小。或者，保留巨大的虚拟地址空间区域，然后分配正确对齐的内存区域（即实现一种对齐的堆）。但我想知道是否有其他选择。例如特殊的 API，可能是一些标志、秘密系统调用或其他什么。
(1)其实很容易解决。正如您所注意到的，munmap采用 size 参数，这是因为munmap能够部分解除分配。因此，您可以分配一块比您需要的更大的内存，然后释放未对齐的部分。