Preventing garbage collection of entities

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Preventing garbage collection of entities

Sergey Zakharchenko
Hello list,

I've long since noticed the fixedgc, luaC_fix, etc. stuff in internals
of newer Lua (it used to be luaS_fix, but generalized since --- a good
thing IMHO). I see some value in it if it could be exposed to user
code instead of remaining an implementation detail (I also think I see
how it can be a problem). Is there any chance of this happening or is
it hidden deliberately?

Best regards,

--
DoubleF

P.S. One way to avoid off-topic conversations is, well, actually
having a more on-topic conversation.

Reply | Threaded
Open this post in threaded view
|

Re: Preventing garbage collection of entities

Kaj Eijlers
If you hold a reference to them they won't be garbage collected, if you don't hold a reference to them how will you be able to keep them alive/address them/ever delete them?

Or am I missing a usecase (entities with coroutines or something?)

On Tue, Dec 4, 2018 at 10:07 PM Sergey Zakharchenko <[hidden email]> wrote:
Hello list,

I've long since noticed the fixedgc, luaC_fix, etc. stuff in internals
of newer Lua (it used to be luaS_fix, but generalized since --- a good
thing IMHO). I see some value in it if it could be exposed to user
code instead of remaining an implementation detail (I also think I see
how it can be a problem). Is there any chance of this happening or is
it hidden deliberately?

Best regards,

--
DoubleF

P.S. One way to avoid off-topic conversations is, well, actually
having a more on-topic conversation.

Reply | Threaded
Open this post in threaded view
|

Re: Preventing garbage collection of entities

Sergey Zakharchenko
Hello Kaj,

Kaj Eijlers <[hidden email]>:
> Or am I missing a usecase (entities with coroutines or something?)

I was thinking of excluding a large range of unchanging entities,
which are guaranteed to be needed throughout the whole program
execution, from garbage collection (so that they aren't walked over
all the time). Holding them in a global table is obvious; I'm after
performance here. Hypothetical ability to share a set of such objects
between Lua states in separate (kernel) threads could be a nice bonus.

Best regards,

--
DoubleF

Reply | Threaded
Open this post in threaded view
|

Re: Preventing garbage collection of entities

Kaj Eijlers
Ah, I see - it’s to exclude them from the mark and sweep. Have you tried doing it from C to see what the savings would be in a true use-case?

Have a bit trouble seeing how that would work, as the dependencies still would need to be marked? Or should those be made non-GC on assignment? That could get tricky if multiple entities can reference them?
Reply | Threaded
Open this post in threaded view
|

Re: Preventing garbage collection of entities

Sergey Zakharchenko
Kaj,

> Ah, I see - it’s to exclude them from the mark and sweep. Have you tried doing it from C to see what the savings would be in a true use-case?

It doesn't make sense for me to try if the functionality is
deliberately hidden and may go away any time, which is what my
question is largely about.

> Have a bit trouble seeing how that would work, as the dependencies still would need to be marked? Or should those be made non-GC on assignment? That could get tricky if multiple entities can reference them?

Correct, the set of entities that could be stored that way would be
quite restricted (nested tables, functions without upvalues, or make
the first upvalue somehow 'not count' as a non-GC reference in Lua
5.2+, probably other pitfalls) but it could still be useful. It's
really complicated to expose that to Lua code but could be doable from
the C API...

Best regards,

--
DoubleF

Reply | Threaded
Open this post in threaded view
|

Re: Preventing garbage collection of entities

Roberto Ierusalimschy
In reply to this post by Sergey Zakharchenko
> I've long since noticed the fixedgc, luaC_fix, etc. stuff in internals
> of newer Lua (it used to be luaS_fix, but generalized since --- a good
> thing IMHO). I see some value in it if it could be exposed to user
> code instead of remaining an implementation detail (I also think I see
> how it can be a problem). Is there any chance of this happening or is
> it hidden deliberately?

Despite the new names, these functions are used only over strings, which
have no references to other objects. As already discussed by others, it
would be quite complicated to expose this to other objects.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Preventing garbage collection of entities

Sergey Zakharchenko
Roberto Ierusalimschy <[hidden email]>:
> Despite the new names, these functions are used only over strings, which
> have no references to other objects. As already discussed by others, it
> would be quite complicated to expose this to other objects.

Still, while this is complicated, does it make sense at least in
theory? Do you intend the base functionality (e.g. the fixedgc list)
to stay?

Best regards,

--
DoubleF

Reply | Threaded
Open this post in threaded view
|

Re: Preventing garbage collection of entities

Javier Guerra Giraldez
On Wed, 5 Dec 2018 at 11:39, Sergey Zakharchenko
<[hidden email]> wrote:
> Still, while this is complicated, does it make sense at least in
> theory? Do you intend the base functionality (e.g. the fixedgc list)
> to stay?

the IPONWEB guys did that for their LuaJIT fork.  i couldn't find the
video, but the slides are here:
https://www.lua.org/wshop18/Soldatov.pdf  immutability starts at slide
#35


--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: Preventing garbage collection of entities

Sergey Zakharchenko
Javier Guerra Giraldez <[hidden email]>:
> the IPONWEB guys did that for their LuaJIT fork.

Thanks for the link; they still have the "interesting" stuff in future
plans though. Frankly I just noticed the luaS_fix->luaC_fix
generalization and wondered if this could be part of mainstream Lua
one day...

Best regards,

--
DoubleF