It appears LuaJIT employs optimizations that assume that its pointers fit in 31 bits. This wouldn't be particularly surprising, fast interpreters often try and steal bits from pointers for lots of reasons, e.g. inlining values (so the indirection is eliminated), encoding the class type in the pointer (some JVMs have done this), etc.
LuaJIT stores non-number objects as NaN floating point values. (A NaN value has 48 bits of payload which can be set to anything.) LuaJIT uses 16 bits of that value for the type and the remaining 32 bits as payload, so pointers are limited to 32 bits.
