Comment by shakna
2 months ago
Why VirtualAlloc?
Lua has its own allocator, which will also collect for you. lua_newuserdata. At the expense of having to set executable yourself, but without all the inbuilt inefficiencies the article points out.
2 months ago
Why VirtualAlloc?
Lua has its own allocator, which will also collect for you. lua_newuserdata. At the expense of having to set executable yourself, but without all the inbuilt inefficiencies the article points out.
Can you set arbitrary memory allocated by malloc (e.g. HeapAlloc in Windows) to executable, via VirtualProtect or something else? If so, that's news to me. I thought it had to be memory allocated by VirtualAlloc only.
That said, I'm not sure that solution beats out this one. I'm using a linked list on top of an arena allocator in practice, which means allocations happen once every 0x10000 bytes. (A single C closure of mine takes up exactly 16 bytes, which includes the pointer to the next linked list node. I'm very happy with how it's designed.)
Lua lets you set the allocator, so you don't have to manage the lifetime.
Two problems with that.
First, it would mean that all Lua objects would be allocated in memory that's potentially executable. That might not necessarily be more of a security issue than the app inherently allows, but at least it's wasteful.
Second, I'm not entirely sure it's a good idea to have C callbacks be collectable, which is why currently they aren't, and you have to free them manually via my winapi.freecallback function. This is part of the inherent issue in the fact that the Windows API has its own concept of lifetimes that are different than Lua's collection visibility. I would like to try to tie them together if possible one day, I'm just not entirely sure how yet.