On 15/01/20 23:22, Sean Conner wrote:
Well, it
certainly is an interesting idea. But it has many drawbacks:
* It only works for one state at a time (if I get your
approach right)
I didn't get that impression at all. lua_newstate() takes a
allocation
function and a pointer to user data (it's luaL_newstate() that
uses
malloc()/realloc()/free()). It's simple enough to say, give 5M
to each
state (or 50M or whatever limit you want).
Exactly. Create one linear allocator per Lua state.
* There will
be a lot of dead memory (Lua uses realloc shrinking often)
Andre did mention it was for short-lived scripts, and not for
something
that runs for a long time (hours? days? For ever?)
That was my use case. In my implementation, I didn't allocate new
memory when the block was shrinking, in this case I just updated
the block header with the new size.
I've also added dlmalloc [1] on top of the linear allocator,
dlmalloc would request new memory blocks from the linear allocator
whenever it couldn't satisfy an allocation request. You still have
a hard limit on the maximum memory for each state, but with 64-bit
OSes you can in theory have 4 billion+ 4 GiB linear allocators
which should be enough for everyone (TM). Both the Lua and the
dlmalloc states were reset with memcpy at the end of script
execution, so it wasn't necessary to event close the state to free
up memory.
Cheers,
Andre
[1]
http://gee.cs.oswego.edu/dl/html/malloc.html
