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.

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.

View all posts by Ben Supnik →