Incorrect range calculation in mcode_alloc()

[akopytov]

The random address selection loop in mcode_alloc() unnecessarily reduces the available allocation range by 2 times:

    /* Next try probing pseudo-random addresses. */
    do {
      hint = (0x78fb ^ LJ_PRNG_BITS(J, 15)) << 16;  /* 64K aligned. */
    } while (!(hint + sz < range));
    hint = target + hint - (range>>1);

Two problems here:

• we probably want LJ_PRNG_BITS(J, LJ_TARGET_JUMPRANGE-16) there, otherwise we may be wasting cycles on architectures with LJ_TARGET_JUMPRANGE < 31
• to get a block within the [target - range; target + range) range (since range is already half the available jump range) we want to check hint + sz against range * 2, then subtract range.

This is likely a minor issue for x86, where the available jump range is big. This becomes a big problem for architectures where the available range is already small (e.g. ARM64 with the +-128 MB range) and there are many parallel threads, amplifying contention on mmap() that I reported earlier in the mailing list.

[akopytov]

Updated the report to remove the first part -- that code in mcode_alloc() is actually correct.

[akopytov]

There are other issues in mcode_alloc() contributing to mmap() contention. I'm going to report the separately.

[MikePall]

Applied. Thanks!