jarcode-foss
commented
8 years ago LuaJIT has a memory issue where it can only take up the 32-bit address space in a given process. This works out to be about ~1G of memory on most linux kernels, and will not play nicely alongside the JVM and multiple lua states.
The standard Lua interpreter has been added instead, which allows me to provide my own memory allocator. Performance improvements will be much less noticable, but LuaJIT 3.x apparently will have changes to its allocation and garbage collection that may allow me to use that instead in the future.
upon some research, looks like LuaJIT is a much faster option than running LuaJ. I am planning to abstract out the interpreters (there will still only be a single interpreter in use), but I'm going to keep LuaJ around just for legacy support.
Advantages of running LuaJIT is also being able to control the heap space, where in LuaJ you could easily exploit the scripting and cause memory leaks. I will be using pthread affinities and priorities to throttle the programs instead of interrupting steps (which is a hell of a lot better way of doing things).