Linux/ARM64: Make mremap() non-moving due to VA space woes.

This reduces overall performance on ARM64, but we have no choice.
Linux kernel default userspace VA is 48 bit, but we'd need 47 bit.
mremap() ignores address hints due to a kernel API issue. The mapping
may move to an undesired address which will cause an assert or crash.

Reported by Raymond W. Ko.

(cherry picked from commit 67dbec8)

47-bit VA space is required by LuaJIT for keeping a GC object pointer in
TValue. In case of huge blobs that are mapped directly, `mremap()` may
move the chunk out of 47-bit range of VA space on ARM64. `mremap()`
accepts the fifth argument (new address hint) only with MREMAP_FIXED
flag. In that case it unmaps any other mapping to specified address.

To avoid this behaviour this patch restricts `mremap()` to relocate
the mapping to a new virtual address by setting CALL_MREMAP_NOMOVE flag
instead of CALL_MREMAP_MAYMOVE for arm64 architecture.

Sergey Kaplun:
* added the description and the test for the problem

Needed for tarantool/tarantool#6154
Part of tarantool/tarantool#5629

Reviewed-by: Igor Munkin <[email protected]>
Reviewed-by: Sergey Ostanevich <[email protected]>
Signed-off-by: Igor Munkin <[email protected]>

Author: Mike Pall

src/lj_alloc.c

@@ -378,7 +378,7 @@ static void *CALL_MREMAP_(void *ptr, size_t osz, size_t nsz, int flags)
 #define CALL_MREMAP(addr, osz, nsz, mv) CALL_MREMAP_((addr), (osz), (nsz), (mv))
 #define CALL_MREMAP_NOMOVE	0
 #define CALL_MREMAP_MAYMOVE	1
-#if LJ_64 && !LJ_GC64
+#if LJ_64 && (!LJ_GC64 || LJ_TARGET_ARM64)
 #define CALL_MREMAP_MV		CALL_MREMAP_NOMOVE
 #else
 #define CALL_MREMAP_MV		CALL_MREMAP_MAYMOVE

test/tarantool-tests/lj-671-arm64-assert-after-mremap.test.lua

@@ -0,0 +1,24 @@
+local tap = require('tap')
+
+-- Test file to demonstrate assertion after `mremap()` on arm64.
+-- See also, https://github.com/LuaJIT/LuaJIT/issues/671.
+
+local test = tap.test('lj-671-arm64-assert-after-mremap')
+test:plan(1)
+
+-- `mremap()` is used on Linux to remap directly mapped big
+-- (>=DEFAULT_MMAP_THRESHOLD) memory chunks.
+-- The simplest way to test memory move is to allocate the huge
+-- memory chunk for string buffer directly and reallocate it
+-- after.
+-- To allocate a memory buffer with the size up to the threshold
+-- for direct mapping `string.rep()` is used with the length that
+-- equals to DEFAULT_MMAP_THRESHOLD.
+-- Then concatenate the directly mapped result string with the
+-- other one to trigger buffer reallocation and its remapping.
+
+local DEFAULT_MMAP_THRESHOLD = 128 * 1024
+local s = string.rep('x', DEFAULT_MMAP_THRESHOLD)..'x'
+test:ok(s)
+
+os.exit(test:check() and 0 or 1)