lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

Hello,


  * 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).


Yes, but you give Lua pointers to *your buffer*. The already initialized
state that gets stored in the background only works with exactly this
buffer and you cannot copy it into another buffer.
Therefore, if you want to have two Lua states, you need to do the initialization + backup trick twice. 




  * 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?)


Yes it will work well with scripts that are short lived, don't use
much data and get destroyed and re-run a lot. This is just a very
narrow use-case.




  * It assumes you have enough virtual memory (only x64)
  * vm.overcommit_memory or equivalent must be enabled
  * Users will complain about what top/Taks manager shows them
  * Memory use has an hard upper limit now; or you need to check it for
every allocation


   It sounds like a hard upper limit.  And there's *always* a hard upper
limit, even with VM.  It's just that in most cases, you'll never hit it.

   I can see this method working for the right work case.

   -spc


With the default malloc, this upper limit is your main memory (+ swap
partition if you have that). But with an arena allocator the upper limit
would be  50MB since realloc/mremap may copy your area to another place,
which cannot be handled by the area allocator.

Greetings