我们有一个具有 32 位地址空间的进程，它需要访问比它可以直接寻址的更多的内存。此过程的大部分源代码无法更改。我们可以更改用于管理数据访问的模块。这些模块的接口可能包括识别要访问的内存的 64 位数据。
我们目前有一个实现，其中接口模块使用与 64 位进程的进程间通信来将数据传入和传出该 64 位进程的地址空间。
有没有更好的办法？
问问题
274 次
2 回答
3
很少有平台支持混合 32 位和 64 位代码。如果您需要超过 2 或 3 GB 的地址空间，您的选择是：
将整个应用程序重新编译为 64 位，或
使用内存映射文件来分页进出大块数据。
重新编译很容易。在 32 位程序中访问超过 2 或 3 GB 的内存是很困难的。
请注意，将 32 位应用程序重新编译为 64 位应用程序不需要更改您的代码或功能，除非您的代码具有不可移植的结构可能会出现一些错误。像：
size_t round_to_16(size_t x)
{
return x & ~15; // BUG in 64-bit code, should be ~(size_t) 15
}
于 2013-07-31T18:09:25.467 回答
1
正如各种评论中所述，情况是：
- 有一个 32 位进程，其中一小部分可以更改。其余的基本上是预编译的，不能更改。
- 小部分当前与 64 位进程通信，以在 64 位地址空间和 32 位进程的地址空间之间传输选定的数据。
- 您寻求替代品，可能具有更高的性能。
进程间通信通常很快。可能没有更快的方法，除非：
- 您的系统具有用于加速内存传输的专用硬件，或者
- 您的系统具有重新映射内存的方法（更多内容见下文）。
Unix 有诸如shmat和mmap允许进程附加到共享内存段并将其地址空间的一部分映射到共享内存段内的偏移量的调用。此类调用可能支持将 32 位地址空间的部分映射到存在于大型物理地址空间中的大型共享内存段。
例如，调用mmap需要一个void *参数来表示要在进程地址空间中映射的地址，以及一个off_t用于将偏移量转换为共享内存段的参数。可以想象，该off_t类型可能是 64 位类型，即使void *它只是一个 32 位指针。我没有对此进行调查。
可以想象，重新映射内存比通过复制操作传输内存更快，因为它可能涉及简单地更改虚拟地址映射而不是物理移动数据。
于 2013-07-31T19:44:57.667 回答