X-Plane 10.22: LuaJIT Memory for Windows and Linux

There are a number of changes to how X-Plane 10.22 beta 1 handles memory for LuaJIT plugins.

Windows and Linux 64-bit: X-Plane Manages Memory

Previously, 64-bit Windows and Linux LuaJIT plugins had to allocate their own memory, and often they did not succeed.  64-bit LuaJIT can only use certain special areas* of memory; if, by the time a LuaJIT-based plugin loads, some other code has used all of that memory, then the LuaJIT plugin cannot operate.

With 10.22 beta 1, X-Plane pre-allocates as much low memory as it can and then provides it to LuaJIT plugins on demand.

This change should fix problems where LuaJIT-based plugins run out of memory, fail to load, etc. on Windows with lots of scenery packs and rendering settings cranked up.

If you ship a plugin that uses LuaJIT, make sure your plugin can use the memory provided by X-Plane.  The process for doing this was defined during the X-Plane 10.20 beta and has not changed, so plugins that are coded correctly will just work.

OS X 64-bit: Crash Fix

Previously for OS X, when a LuaJIT used up all available low memory that X-Plane had reserved, X-Plane would crash.  This was a bug in our code; X-Plane now correctly simply tells the plugin "sorry, we're out of memory for you."

I have said this before in forum posts and I will say it again: your plugin should not exhaust Lua memory! There is typically over 1 GB of LuaJIT memory available; if your plugin exhausts it all, your plugin is doing something wrong.

So it's good that this won't crash, but if there were plugins that were causing this crash, those plugins probably need to be carefully examined - their memory use was way too high!

New Stats to Monitor Memory Use

There are two new "stats" in DataRefEditor (pick the "show stats" sub-menu option) for Lua memory use: lua/total_bytes_alloc and lua/total_bytes_alloc_maximum.  The first one tells you how many bytes of memory all Lua plugins are using, the second shows the highest memory allocation ever recorded.  A few notes:

  • This only measures memory use provided by X-Plane.  So 32-bit plugins will show "0" for both, because in 32-bit plugins, X-Plane does not provide memory to Lua.
  • Lua is garbage-collected, meaning it allocates memory for a while, then periodically throws out unused stuff.  So it is normal to see this value slowly rise over time, then periodically drop down by quite a bit.  It is not normal to see these values increase indefinitely without ever dropping down.
  • If your 64-bit Windows plugin uses LuaJIT but registers "0" for lua/total_bytes_alloc, your plugin is not getting memory from X-Plane and is not working correctly; fix your plugin ASAP!
  • This memory includes allocations by Lua scripts.  It does not include memory for textures, sounds, and other "native" resources provided by SASL or Gizmo.  So you should not see a 4 MB allocation just because you made a 1024 x 1024 texture, for example.

* The lowest 2 GB of virtual memory, to be specific.  Most other code running in X-Plane (the sim itself, the OpenGL driver, OpenAL, the operating system, other plugins) can use any memory, but they tend to consume some of this "LuaJIT-friendly" memory during normal operations.  Thus X-Plane's strategy is to pre-allocate the LuaJIT-friendly memory and reserve it only for LuaJIT use.


  • Facebook
  • Reddit
  • Twitter
  • LinkedIn

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.
This entry was posted in Aircraft, Development. Bookmark the permalink.

11 Responses to X-Plane 10.22: LuaJIT Memory for Windows and Linux

  1. Markus says:

    Thanks for fixing the OSX crash!

  2. Tom Knudsen says:

    Could you please describe the difference between LUA and SALS..
    Are both programming languagues or libraries for c? Do you allocate memory with malloc or calloc and finally are the SALS bug still beeing fixed in 10.30?

    • Ben Supnik says:

      Lua is a programming language used for scripting.
      LuaJIT is a C library that runs Lua scripts very quickly.
      SASL is one of several X-Plane plugins that contains LuaJIT (to run scripts) and also provides extra functionality to plugins.

      X-Plane allocates memory with malloc.

      Re: SASL bugs, I do not know what SASL bugs you are referring to; the question doesn't make a ton of sense. A bug in SASL will be fixed by the SASL developers, a bug in X-Plane will be fixed by X-Plane.

      • Tom Knudsen says:

        Thank you Ben

        In reference to the bug: I keep seeing talks on the forums of x-plane.org that there is a memory bug in 64bit that has something to do with SALS. An thing that is supposedly going to get fixed in 10.30. Not sure what it is but nevertheless the new Ramzess 757 is supposedly on hold untill this is fixed in 10.30.

        Not sure, but I think it has something to do with why 64bit SALS is crashing the sim with planes that uses the SALS plugin

        Anyway, thanks for explaining in detail Ben, love to learn!

        • Ben Supnik says:

          Everything that is known about and fixed is described in the release notes and this blog post.

          There are no remaining LuaJIT issues with X-Plane - 10.22b1 fixes everything on our end.

  3. Ropeless says:

    Hi Ben,
    I'm writing a LuaJIT plugin presently. Can you point us to some doc on how to correctly do the memory allocation for X-Plane. If it's just a custom allocator, is the code available somewhere?

    Cheers,
    Ropeless

  4. Wigry says:

    Hi,

    Is it expected that the ridiculous 2GB limit will be lifted at some point in the future. I believe that as long as that limit exists, the problem is still there. In todays 64-bit systems the 2 GB limit is such a ridiculous excuse for bad architecture that I cannot find the words ti describe my surprise and disbelief.

    • Ben Supnik says:

      Sort of. The LuaJIT developers are working on a new garbage collector that will let them use 4 GB of space, but they are not planning on changing the 64-bit code gen to allow for a full-size memory arena.

Comments are closed.