lua-users home
lua-l archive

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


So trying to do something like this would interfere with the GC? But
Yea I just want to store the bytecode of the code in one spot and not
have other copies all over the place in memory when I have multiple
VMs.

On Wed, Oct 18, 2023 at 1:43 PM Sean Conner <sean@conman.org> wrote:
>
> It was thus said that the Great Iurii Belobeev once stated:
> > On Wed, 18 Oct 2023 at 21:36, Keith Cancel <admin@keith.pro> wrote:
> >
> > > I was looking at the source code trying to see if there was a way
> > > maybe to achieve something similar to lua_load(), but at compile time.
> > > Basically, I want to bunch a shared code to only occupy the memory
> > > once instead of creating copies for each new lua VM instance. I
> > > basically just want that code in ROM that can be executed by each new
> > > instance without having to copy it over first.
> >
> > you can precompile lua text source by calling lua_dump and safely put it
> > into shared memory. it will produce binary chunk which then can be
> > converted to lua function by calling lua_load on it. you cannot reuse
> > result of lua_load since global table _G is pushed as upvalue to the
> > resulting function, i.e. is not reusable.
>
>   I don't think that will acccomplish what Keith asked for.  I think Keith
> is asking, can I, once Lua code is compiled, share the resulting VM code
> among different Lua states in the same process?  Yes, you can use lua_dump()
> and store the code into shared memory (either at run time, or at compile
> time [1]), but when calling lua_load() memory is allocated to store the code
> into the currently running VM.
>
>   An approach would be to get pointers to the underlying structures in the
> initial VM, and then somehow make them available to another VM, but you
> would have to ensure the structures are immune to garbage collection, else
> bad things could happen.  That might be good for a hack, but not for
> production code.
>
>   -spc
>
> [1]     As I outlined here: https://boston.conman.org/2023/03/22.1