在 64 位平台上，LuaJIT 最多只允许 1-2GB 的数据（不包括分配的对象）malloc）。这个限制从何而来？为什么这个限制比 32 位平台上的还要少？
LuaJIT 被设计为使用 32 位指针。在x64平台的限制来自于使用mmap和MAP_32BIT flag.
MAP_32BIT（自 Linux 2.4.20、2.6 起）：
将映射放入进程地址空间的前 2 GB 中。对于 64 位程序，此标志仅在 x86-64 上受支持。添加它是为了允许在前 2GB 内存中的某个位置分配线程堆栈，从而提高某些早期 64 位处理器上的上下文切换性能。
本质上，使用此标志仅限于前 31 位，而不是顾名思义的前 32 位。看一看here有关 1GB 限制的详细概述，请使用MAP_32BIT在Linux内核中。
即使您可以拥有超过 1GB，LuaJIT 作者也解释了为什么这会影响性能：
- 完整的 GC 比分配本身多花费 50% 的时间。
- 如果启用 GC，分配时间会加倍。
- 为了模拟真实的应用程序，对象之间的链接在第三次运行中被随机化。这使得 GC 时间加倍！
那只是 1GB！现在想象一下使用 8GB —— 一个完整的 GC 周期将使 CPU 忙碌长达 24 秒！
好的，那么正常模式就是使用增量GC。但这仅仅意味着开销高出约 30%，它混合在分配之间，并且每次都会逐出 CPU 缓存。基本上你的应用程序将由 GC 开销主导，你会开始想知道为什么它很慢......
tl;dr 版本：不要在家尝试这个。并且GC需要重写（推迟到LuaJIT 2.1）。
总而言之，1GB 限制是 Linux 内核和 LuaJIT 垃圾收集器的限制。这仅适用于 LuaJIT 状态内的对象，并且可以通过使用来克服malloc，它将在低 32 位地址空间之外进行分配。此外，还可以使用x86建立在x64在 32 位模式下，可以访问完整的 4GB。
查看这些链接以获取更多信息：
- 如何在 Linux 上突破 64 位 LuaJIT 的 1GB 内存限制？
- LuaJIT x64 仅限于 31 位地址空间，即使没有 MAP_32BIT 限制？
- LuaJIT奇怪的内存限制
- 挖掘 2008 年以来你从未听说过的最疯狂的 bug：Linux 线程回归
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
