MAP_32BIT (since Linux 2.4.20,2.6):

Put the mapping into the first 2 Gigabytes of the process address space. This flag is supported only on x86-64,for 64-bit programs. It was added to allow thread stacks to be allocated somewhere in the first 2GB of memory,so as to improve context-switch performance on some early 64-bit processors.

基本上使用此标志限制为前31位,而不是名称建议的前32位.在Linux内核中使用MAP_32BIT查看here以获得1GB限制的概述.

即使你的内容超过1GB,LuaJIT作者也解释了为什么这对性能有害：

• A full GC takes 50% more time than the allocations themselves.
• If the GC is enabled,it doubles the allocation time.
• To simulate a real application,the links between objects are randomized in the third run. This doubles the GC time!

And that was just for 1GB! Now imagine using 8GB — a full GC cycle would keep the @R_301_456@ busy for a whopping 24 seconds!
Ok,so the normal mode is to use the incremental GC. But this just means the overhead is ~30% higher,it’s mixed in between the allocations and it will evict the @R_301_456@ cache every time. Basically your application will be dominated by the GC overhead and you’ll begin to wonder why it’s slow ….

tl;dr version: Don’t try this at home. And the GC needs a rewrite (postponed to LuaJIT 2.1).

总而言之,1GB限制是Linux内核和LuaJIT垃圾收集器的限制.这仅适用于LuaJIT状态内的对象,可以通过使用malloc来克服,malloc将在较低的32位地址空间之外进行分配.此外,它可以在32位模式下在x64上使用x86构建,并可以访问完整的4GB.

查看这些链接以获取更多信息：

> How to get past 1gb memory limit of 64 bit LuaJIT on Linux?
> LuaJIT x64 limited to 31 bit address space,even without MAP_32BIT restrictions?
> LuaJIT strange memory limit
> Digging out the craziest bug you never heard about from 2008: a linux threading regression