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,

[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 <

Post by 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.

[Sergey Zakharchenko]

Hello Kaj,

Post by Kaj Eijlers
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,

[b***@gmail.com]

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?

[Sergey Zakharchenko]

Kaj,

Post by b***@gmail.com
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.

Post by b***@gmail.com
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,

[Roberto Ierusalimschy]

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

[Sergey Zakharchenko]

Post by Roberto Ierusalimschy
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,

[Javier Guerra Giraldez]

On Wed, 5 Dec 2018 at 11:39, Sergey Zakharchenko

Post by Sergey Zakharchenko
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

[Sergey Zakharchenko]

Post by Javier Guerra Giraldez
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