Support up to 48bit addresses in LJ_GC64 mode.

[daurnimator]

Continuing from #49 (comment)

Actually... don't we know the alignment of GC objects is to 8 bytes; and hence have an extra 3 bits to work with?
Lightuserdata is user provided, so we have to store the full 48 bits. This demands a variable length encoding such as:

** 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|111|----48 bit pointer---|
** GC objects       |1111111111111|1??|---45 bit GCRef--|???|

---

Tag bits toward the MSB are far more convenient than tag bits at the LSB,
and keeping all the tag bits together is also convenient.

I'd be tempted to keep 4 bits of tag in the current position, give lightuserdata two tag values (i.e. encode their 48th address bit in the tag), and fit GC object pointers into 47 bits by dropping the least significant bit of their address (which, as already noted, we can do thanks to alignment).

---

This issue explicitly does not aim to support 52 bit addresses. (as they cannot fit within a NAN's spare bits)

[NukeRusich]

Let's wait until after we have LJ_GC64 mode.

[MikePall]

Obsoleted, due to changes in the memory block allocator.

[daurnimator]

Obsoleted, due to changes in the memory block allocator.

Do you think this is something we might need again in future?

[MikePall]

Unlikely. It's not a general solution and it has an overall negative performance impact.

Also, you're probably heavily underestimating the scope of such a change. A couple thousand lines and lots of added complexity.