47 bit address space restriction on ARM64

[dodiadodia]

Hi, I encounter a problem to run luajit-2.1 on ARM64 platform, as follow:
My kernel enable "AArch64 Linux memory layout with 64KB pages + 3 levels", show at "https://www.kernel.org/doc/Documentation/arm64/memory.txt". So I have 48 bits Virtual Address.
But in the luajit lj_obj.c, that said "64 bit platform, 47 bit pointers", and when the code use the "LJ_GCVMASK" to get the real pointers, return value is wrong, the 48 bits VA is cut to 47 bits length. So the luajit program get the SIGSEGV signal.
We can use the "AArch64 Linux memory layout with 64KB pages + 2 levels" in our kernel that have 42bits VA, that will resolve this problem, but because of some limitations we can't use this mode.
So how can I resolve this problem?

[MikePall]

Sorry, but I don't think there's an easy way to solve this. The 47 bit restriction is pretty much hardcoded due to the use of NaN-tagging: 13 bits to indicate NaN, 4 bits for the tag, 47 bits left.

However, I doubt that it makes much of a difference for your user mode whether it gets 2^47 or 2^48 bytes of address space. :-) So, your kernel could just hand out pages in the lowest 2^47 bytes of the address space.

AFAIR there are memory region settings that can be tuned somewhere in the arch section, but this is more a question for Linux kernel experts then.

[dodiadodia]

I track the source code to src/lj_api.c, in "getcurrenv" function.
We will get GCfunc *fn from "lua_State *L", and we can see that L address is 0xffff7a190378, and the fn address is 0x7fff7a190378, the 48th bit the L is turned to 0, as we debug on level 2 memory layout, the L address is equal to fn, so now we guess the fn address is illegal, when we access the fn, the program receive SIGSEGV signal and exit.
The curr_func(L) is using the gcval macro that will use "LJ_GCVMASK" to get the 47 bit address.

[MikePall]

Yes, this is expected. For LJ_GC64 mode, all addresses need to be in the range from 0 to 0x7fff_ffff_ffff. I.e. the lowest 2^47 bytes of the address space.

[DemiMarie]

One solution would be to call mmap with MAP_FIXED, to force the kernel to give out addresses in the right range (or fail, which would cause a LuaJIT panic). This would require some non-portable hacks to find a viable starting address, or using /proc/self/maps to find a free area. Steel Bank Common Lisp (SBCL) uses a fixed address on all supported platforms, though for a different reason (SBCL core images are not position independent and must be loaded to the same address every time).

[dodiadodia]

Yes, I tried it and it's a method can temporary resolve the problem.
Thank you.

[apinski-cavium]

stack is allocated with the 48bit set. So nothing here is a valuable option. Please reopen this bug. This is an important bug. We need to use 48bit VA as our PA is uses the full 48bits.

[apinski-cavium]

Oh one more point ARMv8.2 will bring in the ability to do 52bit VA. This is going to be a mess in the server business if this is not supported. I am going to try to hack up this by removing this whole overload usage. Compression is just a joke when it comes to small and fast languages.

[DemiMarie]

I can see a couple options:

• Give up NaN-boxing (but that is a perf loss as well as requiring major
  changes)
• Use mmap to reserve a massive address space at startup. Then allocate
  everything from this address space.

I strongly suspect that the second approach will work. Lua code in LuaJIT
does not use the C stack and SpiderMonkey has the same problems as LuaJIT I
believe.
On Feb 25, 2016 1:50 AM, "apinski-cavium" notifications@github.com wrote:

Oh one more point ARMv8.2 will bring in the ability to do 52bit VA. This
is going to be a mess in the server business if this is not supported. I am
going to try to hack up this by removing this whole overload usage.
Compression is just a joke when it comes to small and fast languages.

—
Reply to this email directly or view it on GitHub
#49 (comment).

[wookey]

As there is now arm64 support in luajit2.1 this came up in Debian. Currently laujit just segfaults immediately because the pointers get the top bit clipped. I hacked about a bit before reaching an understanding that we can't just move everything up by one bit without losing tag space or the 'NaN-boxing'. Anyway there is a debian bug here tracking the issue.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818616

As apinski says, we need to allow for 52-bit pointers soon (and so will x86), so a long-term solution involves changing the layout.
I see from https://bugzilla.mozilla.org/show_bug.cgi?id=1143022 that it looks like mmapping was used to make it work there for the time being. We could do the same thing for now.

[MikePall]

The mmap hinting approach described in the Mozilla bug report does not work properly with a (recent) Linux kernel. Neither does their code.

The address passed to mmap is only accepted as a hint if the requested address is not yet allocated.

But if it's already taken, then the hint is ignored and a random base address from the designated mmap VM area is allocated (i.e. outside of the acceptable addresses). The Linux kernel does not perform a linear search starting at the hint address (unlike BSD kernels etc.).

In other words: the user-space memory allocator would need to get a lot more clever about hinting. Otherwise it'll a) fail randomly (especially with different VMs in multiple threads), or b) perform very expensive linear address space searches, and/or c) kill performance due to overly spread-out randomized addresses (think about page tables & TLBs).

[daurnimator]

I don't suppose it's possible to remove one of the type bits so that we have 48 bits available for the GCRef? And then store the GCRef subtype in the GC object itself?

e.g.

** number           -----------------double------------------
** nil              |1111111111111|000|1...................1|
** false            |1111111111111|001|1...................1|
** true             |1111111111111|010|1...................1|
** int (LJ_DUALNUM) |1111111111111|011|0..0|------int-------|
** lightuserdata    |1111111111111|101|----48 bit pointer---|
** GC objects       |1111111111111|111|-----48 bit GCRef----|

This has one bit available for lightuserdata and GC objects. Could extend to 49 bit pointers, or keep the bit free for future/other use.

[DemiMarie]

One approach is to use /proc/self/maps or the like to try to find a suitable unmapped address. Then call mmap with MAP_FIXED to force the kernel to either give you the address you asked for, or fail. Loop on failure. In a single-threaded process, this is guaranteed to terminate the first time. In a multithreaded process, the probability that the loop is still going after n iterations should decrease exponentially with n, provided that the addresses are chosen randomly among the free addresses available (just use /dev/urandom).

The Linux kernel allocates physical memory lazily, and I suspect other kernels do as well. As a result, it is perfectly OK to allocate in GiB-sized chunks – it is routine for programs to allocate 1TB of virtual memory on 64-bit systems.

To mark a page as unused, use mprotect with PROT_NONE.

Finally, I would file a feature request with the kernel about changing the behavior, perhaps with a new flag to mmap.