A few questions about memory allocation

[Sewbacca]

I was wondering the other day how Lua handles memory allocations for a few reasons.

Sometimes it's nice to do calculations on the stack rather than on the heap, if I know that the data is only used within that callframe.
This is especially true for vector calculations. In fact sometimes it would be even better if I could pass vectors by value rather than by reference,
because vectors are most of the time two to four numbers, so treating them like numbers would be nice, but AFAIK Lua doesn't support that directly.
For some applications it would be beneficial to allocate on the stack rather than the heap, even some larger userdatas/tables.

The next best thing would be to preallocate an arena and just hand userdatas with pointers.
If I allocate a userdata object of a small size, say the size of a pointer, does Lua allocate it on the heap or does it manage an arena of some kind?
I suspect it allocates the data on the heap, so it's probably best to allocate the C structure directly in the memory provided by Lua, rather than calling malloc myself and just storing just a pointer right?
Of course could manage my own arena and hand out light userdata objects, but this means I cannot attach different metatables to different pointers.

Any comments and or suggestions would be appreciated!

TLDR;

• Are full userdatas always allocated on the heap, no matter how small (i.e. pointer sized)?
• Allocation wise it is always better to allocate the data directly in the space provided by Lua rather than just saving a pointer and calling malloc?
• Is there a way to do pass by value rather than reference for tables and/or (full) userdatas?
• Is it possible to allocate data on the stack rather than the heap?

[Sainan]

When Lua wants to allocate, resize, or free, an allocation, it defers that job to the 'frealloc' function, which you can pass to lua_newstate or set with lua_setallocf. If instead you use luaL_newstate, the function looks like this:

return nsize == 0 ? (free(ptr), nullptr) : realloc(ptr, nsize);

-- Sainan

[Javier Guerra Giraldez]

On Fri, 20 Feb 2026 at 15:26, 'Sewbacca' via lua-l <lu...@googlegroups.com> wrote:

I was wondering the other day how Lua handles memory allocations for a few reasons.

Sometimes it's nice to do calculations on the stack rather than on the heap, if I know that the data is only used within that callframe.
This is especially true for vector calculations. In fact sometimes it would be even better if I could pass vectors by value rather than by reference,
because vectors are most of the time two to four numbers, so treating them like numbers would be nice, but AFAIK Lua doesn't support that directly.
For some applications it would be beneficial to allocate on the stack rather than the heap, even some larger userdatas/tables.

As in most interpreted, non-JITted languages, The "stack" in Lua actually resides in the heap (as seen from the underlying C implementation).

While I think (could be wrong) primitive values (numbers, booleans, nil, lightuserdata) are passed by value and directly stored in the stack, anything slightly bigger would be handled by reference.  even strings (although the deduplication makes them obey value semantics), or small "vectors" (implemented as tables?) are definitely allocated in the heap and passed by reference.

 

The next best thing would be to preallocate an arena and just hand userdatas with pointers.
If I allocate a userdata object of a small size, say the size of a pointer, does Lua allocate it on the heap or does it manage an arena of some kind?
I suspect it allocates the data on the heap, so it's probably best to allocate the C structure directly in the memory provided by Lua, rather than calling malloc myself and just storing just a pointer right?

yes

 

Of course could manage my own arena and hand out light userdata objects, but this means I cannot attach different metatables to different pointers.

or you could replace the allocator used by Lua with a thin wrapper to malloc that uses an arena for small objects.  i guess some of the many "high performance" allocators do that in very sophisticated ways.

 

--

Javier

[Sewbacca]

On 2/20/2026 10:36 PM, Javier Guerra Giraldez wrote:
>
> or you could replace the allocator used by Lua with a thin wrapper to
> malloc that uses an arena for small objects.  i guess some of the many
> "high performance" allocators do that in very sophisticated ways.

I suppose I could. What I don't like about this solution is that it
doesn't work as an addon (as a C module). You would need to control the
whole application flow for that (I suppose you could exchange the
allocator function midway through, but that seems on another level of
complexity). In C one would simply allocate an arena and return pointers
to objects residing in it, but that would require Lua to handle small
sized userdata differently.

~ Sewbacca

[Sean Conner]

It was thus said that the Great 'Sewbacca' via lua-l once stated:

> I was wondering the other day how Lua handles memory allocations for a
> few reasons.
>

> The next best thing would be to preallocate an arena and just hand
> userdatas with pointers.
> If I allocate a userdata object of a small size, say the size of a
> pointer, does Lua allocate it on the heap or does it manage an arena of
> some kind?
> I suspect it allocates the data on the heap, so it's probably best to
> allocate the C structure directly in the memory provided by Lua, rather
> than calling malloc myself and just storing just a pointer right?
> Of course could manage my own arena and hand out light userdata objects,
> but this means I cannot attach different metatables to different pointers.
>
> Any comments and or suggestions would be appreciated!

Read up on lua_Alloc: <https://www.lua.org/manual/5.5/manual.html#lua_Alloc>

It states:

typedef void * (*lua_Alloc) (void *ud,
void *ptr,
size_t osize,
size_t nsize);

The type of the memory-allocator function used by Lua states. The
allocator function must provide a functionality similar to realloc,
but not exactly the same. Its arguments are ud, an opaque pointer
passed to lua_newstate; ptr, a pointer to the block being
allocated/reallocated/freed; osize, the original size of the block
or some code about what is being allocated; and nsize, the new size
of the block.

When ptr is not NULL, osize is the size of the block pointed by ptr,
that is, the size given when it was allocated or reallocated.

When ptr is NULL, osize encodes the kind of object that Lua is
allocating. osize is any of LUA_TSTRING, LUA_TTABLE, LUA_TFUNCTION,
LUA_TUSERDATA, or LUA_TTHREAD when (and only when) Lua is creating a
new object of that type. When osize is some other value, Lua is
allocating memory for something else.


So just provide your own allocation function (via lua_newstate()). I think
something like:

void *my_alloc(void *ud,void *ptr,size_t osize,size_t nsize)
{
if (ptr == NULL) /* grabbing some memory */
{
if ((osize == LUA_TUSERDATA) && (nsize == sizeof(arenea_object))
return next_arenaobject();
else
return realloc(ptr,nsize);
}
else
{
if (nsize == 0) /* freeing memory */
{
if (is_arenaobject(ptr))
mark_areanaobject_free(ptr);
else
free(ptr);
}
else
return realloc(ptr,nsize);
}
}

-spc

[Denis Dos Santos Silva]

• Is it possible to allocate data on the stack rather than the heap?

 you can try implement a `arena allocator` like using a large buffer