Re: LuaJIT x64 limited to 31 bit address space, even without MAP_32BIT restrictions?

  • From: Theo Schlossnagle <theo.schlossnagle@xxxxxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Wed, 22 Jan 2014 13:25:48 -0500

To put some outside perspective on why this would be valuable to me...

We run some large multi-threaded programs.  B/c Luajit itself isn't
threadsafe, we end up having an independent lua state for each thread (with
lots of coroutines each).  We keep them isolated and talking to each other
through types of message passing and threadsafe C-side data structures.  It
works exceptionally well... but.

With 32 cores on a box and 32 corresponding lua interpreters, we're limited
to 2^31/2^5 byes of addressable space. (2^26 -> 64MB).  That can go fast.
 We currently play tricks to make sure almost all of the lower 32 bits of
address space are available for mmap -- this has held us over so far, but
we have to drop to 16 interpreters at times b/c of this limitation.

I know it's a huge change and frankly don't expect it to happen, but being
able to either use 31bits from an arbitrary base address (meaning I could
use 2Gb per interpreter) or using closer to 48 bits would allow us to do
more with what we have today.

Just my two cents.  Thanks for all the work on LuaJIT it has been awesome
for us.

Best regards,

Theo


On Wed, Jan 22, 2014 at 3:17 AM, Mike Pall <mike-1401@xxxxxxxxxx> wrote:

> Cheng, Long wrote:
> > Can you share more detail on why the 31st bit is not usable? We
> > really want to be able to use more than 2G address space for x64
> > (with a custom mmap allocator).
>
> Then you need to find and fix all instances in the x64 assembler
> backend where constified 32 bit pointers are embedded as offsets
> in x86 addressing modes.
>
> But if you really need that much memory, you're better off using
> unmanaged or indirectly managed memory with the FFI (which allows
> full 64 bit pointers, e.g. to malloc'ed or mmap'ed memory). The
> current GC really isn't up to the task of managing 4 GB filled
> with small objects with reasonable efficiency.
>
> --Mike
>
>

Other related posts:

  1. Home
  2. luajit
  3. Archive
  4. 01-2014