Re: Scalability of Lua, many small vs. few big lua_States?

[Tim Hill <drtimhill@...>]

> 
> Doesn't a lua_State also include its own GC state?
> 
> The implication being that many independent lua_States will each have their own independent (non-interfering) GC contexts, whereas running all tasks as coroutines within a single lua_State will share a single GC context (and potentially interact/interfere).
> 
> Seems to me that allocating and tearing down a lua_State for each task might have more predictable memory behavior (similar to using zones/arenas). Reusing a single lua_State will have behaviour more strongly dependent on the long term behavior of the GC algorithm (which might be good or bad).
> 
> Just some idle conjecture, but I'd be interested to hear the GC aspect discussed.
> 
> Ross.
> 

The term “lua_State” is ambiguous as Lua overloads the use of this structure. When created via lua_newstate() you are created a brand-new, stand-alone Lua instance, with its own GC, registry etc; it will not be connected to any other lua_State created in this way. In this case, each of these lua “states” can run on its own operating system thread and use its own CPU core if available etc etc. This is true multi-threading in the OS sense .. though of course the Lua code in each state cannot interact with Lua code in other states without the help of libraries that tunnel between them (and take care of thread sync details).

However, when you create a co-routine inside Lua, you are also creating a lua_State, but this can be thought of as a “secondary” state (the Lua docs don’t use this terminology). This state has its own stack, but shares global resource including the registry, the GC etc etc. These states are purely co-operative multi-tasking and cannot run on distinct operating system threads (they are really just sophisticated indirect calls inside the Lua VM). In some operating systems these “threads” are sometimes called “fibers” (though Lua doesn’t use OS fibers for coroutines, the concept is similar).

So, SOME lua_States share the GC, but these are ones created inside Lua (as coroutines), while the ones created with lua_newstate() don’t share anything. Thus, having lots of independent states can help in controlling memory bulges causes by lots of pending GCs .. sometimes. Other times it can make it worse as the independence of each primary Lua state makes it harder for the GC to make smart decisions (it is unaware of the total memory across all lua states).

In our systems, where we have a lot of interacting primary Lua states, we “nudge” the GC if a Lua state (a primary state, not a coroutine) has been inactive for a certain period of time (the computation of “certain period” here is quite complex), to try to mitigate states holding too much uncollected garbage.

—TIm