Lua Memory Allocation Patterns for Real-time

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Lua Memory Allocation Patterns for Real-time

Jeremy Jurksztowicz
Hi, probably asked somewhere on the archive but my searches are turning up nil.

Wondering if I can get any understanding of what kind of Lua code I can write that will not invoke the memory allocator.
i.e. if I have a function that does not create any tables or strings, and I make sure that the lua_State has a lot of stack space, and pause the GC, and I only operate on numbers in a preallocated table, would it be reasonable to assume that the code would not block, and be suitable for signal processing?

I have been looking through the code and docs, but if anyone can point to some definitive material or share some caveats or encouragement, I’d really appreciate that.

Regards,
Jeremy J.
Reply | Threaded
Open this post in threaded view
|

Re: Lua Memory Allocation Patterns for Real-time

Russell Haley


On Wed, May 23, 2018 at 8:05 AM, Jeremy Jurksztowicz <[hidden email]> wrote:
Hi, probably asked somewhere on the archive but my searches are turning up nil.

Wondering if I can get any understanding of what kind of Lua code I can write that will not invoke the memory allocator.
i.e. if I have a function that does not create any tables or strings, and I make sure that the lua_State has a lot of stack space, and pause the GC, and I only operate on numbers in a preallocated table, would it be reasonable to assume that the code would not block, and be suitable for signal processing?

I don't know about the memory allocator, but wouldn't you need a polling library to listen for signals and not block? I suspect you could mimic a polling library with a co-routine, but something like cqueues or luasys might be a requirement? I have no idea what environment you're working in so support for polling libraries might be a problem.

cqueues:

Luasys:


I have been looking through the code and docs, but if anyone can point to some definitive material or share some caveats or encouragement, I’d really appreciate that.

Regards,
Jeremy J.

Reply | Threaded
Open this post in threaded view
|

Re: Lua Memory Allocation Patterns for Real-time

Javier Guerra Giraldez


On 23 May 2018 at 17:16, Russell Haley <[hidden email]> wrote:
I don't know about the memory allocator, but wouldn't you need a polling library to listen for signals and not block?

i guess the OP is about defining small functions that could be safely called at any time, not dealing with IO 



--
Javier
Reply | Threaded
Open this post in threaded view
|

Re: Lua Memory Allocation Patterns for Real-time

William Ahern
In reply to this post by Jeremy Jurksztowicz
On Wed, May 23, 2018 at 11:05:03AM -0400, Jeremy Jurksztowicz wrote:
> Hi, probably asked somewhere on the archive but my searches are turning up nil.
>
> Wondering if I can get any understanding of what kind of Lua code I can
> write that will not invoke the memory allocator. i.e. if I have a function
> that does not create any tables or strings, and I make sure that the
> lua_State has a lot of stack space, and pause the GC, and I only operate
> on numbers in a preallocated table, would it be reasonable to assume that
> the code would not block, and be suitable for signal processing?

AFAIU, in that scenario there shouldn't be any allocation. You might want to
carefully read the table code to see if certain access patterns could
trigger a realloc to a smaller hash or array index.

For a recent project I'm likewise expecting this behavior--that simple
scalar operations and read-only table accesses won't trigger allocation.
Though I don't really need a hard guarantee like you do so haven't invested
much time in verifying my assumptions.

Whether or not your code blocks depends on the runtime environment and what
you mean by blocking. Even without allocation or explicit file I/O (directly
or indirectly in the VM), you could still block on a page fault. You might
want to use the allocator hooks so you can pin pages in memory.

> I have been looking through the code and docs, but if anyone can point to
> some definitive material or share some caveats or encouragement, I’d
> really appreciate that.

I don't think there's such definitive material but would be pleasantly
surprised if there is. You may want to check for material or discussions
related to embedded forks like eLua.


Reply | Threaded
Open this post in threaded view
|

Re: Lua Memory Allocation Patterns for Real-time

Philipp Janda
In reply to this post by Jeremy Jurksztowicz
Am 23.05.2018 um 17:05 schröbte Jeremy Jurksztowicz:
> Hi, probably asked somewhere on the archive but my searches are turning up nil.

Hi!

>
> Wondering if I can get any understanding of what kind of Lua code I can write that will not invoke the memory allocator.
> i.e. if I have a function that does not create any tables or strings, and I make sure that the lua_State has a lot of stack space, and pause the GC, and I only operate on numbers in a preallocated table, would it be reasonable to assume that the code would not block, and be suitable for signal processing?
>
> I have been looking through the code and docs, but if anyone can point to some definitive material or share some caveats or encouragement, I’d really appreciate that.

I have no definitive material for you, but I have looked into memory
allocation patterns before and have some tips:

* Stack space is not the only concern. Lua allocates call frames for
function calls. I have used a coroutine which yielded from a recursively
`lua_call`ed C function to preallocate those. (Lua 5.1 is harder to
handle because it doesn't allow yields from C functions, and it has
different call frames for Lua function calls and C function calls.)
* What you should definitely avoid is table literals, writes to
non-existing table fields, new strings (e.g. using string concatenation,
by implicit coercions or tostring calls, or some C API functions, e.g.
luaL_error -- string literals in Lua code are fine because they are
allocated when the chunk is compiled), new Lua functions, coroutines, or
userdata.
* You can replace the current allocator to check whether a piece of code
allocates memory.
* I haven't looked into LuaJIT, but I imagine that JIT compilation will
allocate memory at the most inopportune moments.
* If you plan to use Lua 5.4 when it is released, you should probably
avoid Lua vararg functions (there are plans that those will allocate
tables behind the scenes).

>
> Regards,
> Jeremy J.
>

HTH,
Philipp



Reply | Threaded
Open this post in threaded view
|

Re: Lua Memory Allocation Patterns for Real-time

Thomas Jericke
In reply to this post by Jeremy Jurksztowicz
On 23.05.2018 17:05, Jeremy Jurksztowicz wrote:
Hi, probably asked somewhere on the archive but my searches are turning up nil.

Wondering if I can get any understanding of what kind of Lua code I can write that will not invoke the memory allocator.
i.e. if I have a function that does not create any tables or strings, and I make sure that the lua_State has a lot of stack space, and pause the GC, and I only operate on numbers in a preallocated table, would it be reasonable to assume that the code would not block, and be suitable for signal processing?

I have been looking through the code and docs, but if anyone can point to some definitive material or share some caveats or encouragement, I’d really appreciate that.

Regards,
Jeremy J.
Instead of trying to figure it out based on assumtion and theory I recommend you to test your code in patched Lua built. You can easily set the allocator of Lua and in that you can activate a trace once you call your function.

bool trace_active = false;
void *l_my_alloc (void *ud, void *ptr, size_t osize, size_t nsize) {
    if(trace_active) {
        printf("Lua allocation!");
    }
    lua_Alloc(ud, ptr, osize, nsize);
}

All you have to do is to set trace_active to true just before you call your function and to false right after it. Otherwise you will have many wrong traces.
--
Thomas
Reply | Threaded
Open this post in threaded view
|

Re: Lua Memory Allocation Patterns for Real-time

Roberto Ierusalimschy
In reply to this post by Philipp Janda
> * If you plan to use Lua 5.4 when it is released, you should
> probably avoid Lua vararg functions (there are plans that those will
> allocate tables behind the scenes).

No more (see the last work release).

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Lua Memory Allocation Patterns for Real-time

Soni "They/Them" L.


On 2018-05-24 10:25 AM, Roberto Ierusalimschy wrote:
>> * If you plan to use Lua 5.4 when it is released, you should
>> probably avoid Lua vararg functions (there are plans that those will
>> allocate tables behind the scenes).
> No more (see the last work release).
>
> -- Roberto
>

Oh good my high-performance code will survive another Lua release!

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.