Re: stepping old data in generational GC

[Francisco Olarte <folarte@...>]

Hi:

On Fri, 15 Sept 2023 at 09:46, dormando <dormando@rydia.net> wrote:

> > On Sep 15, 2023, at 12:11 AM, Francisco Olarte <folarte@peoplecall.com> wrote:
...
> > There is your problem, NEED COLLECTION (__gc). GC is good for


> To clear up a little: I did check the ML history and saw people with a pattern like:
> - alloc userdata (8 bytes), which holds a malloc'ed item (8 megabytes) and the GC can't see the malloc so it doesn't run often enough.

That's one of the problematic pattern. Sockets, db connections, open
files, anything which is not similar can get into this problem.

> ...but that's not really happening here. The objects are all just 60 bytes without external memory. The GC is firing plenty, but in GCGEN mode it never visits the older data at all, as it can take a very very long time to alloc enough "old" objects to cause a major collection.

GC firing plenty does not guarantee it collects what you want, it is
not RAII or similar.

> I'm in this pattern taking advantage of lua's memory management to cope with changing the base objects while "requests" are in flight with the old base objects. I can't easily predict when they're not in use anymore.

That's an old problem. For some similar things I do ( manual ) ref
counting in Lua ( basically wrap workers in a pcall and  inc/dec ref
every heavy dependency around it and close()d it as needed, pool like
). The problem is you are trying to use the GC for something it is not
dessigned for. You can make it work, but it is not going to be pretty.
At the end garbage collection languages end up needing try/finally or
whatever substitute you want.

> In some testing I did after my last post I found setting the GCINC params to "199, 200, 13" (default-1, default, default) is able to keep up... but now I'm repeatedly visiting a lot of objects that don't change in searching for all of the recently made garbage. I've also tried to get __close() to do what I want but without luck yet.

if you can use __close() it means you can use <close>, which is a
finally variant, and you have your resource usage delimited, in which
case some refcounting or similar things is easy to do.

> In some idealistic scenario you could either manually step or once-per-minor-young-cull step through specifically old objects. You can switch back to incremental temporarily but I can't predict _when_ the old objects are freeable.

The problem with old objects is you have to step  through every
object, young or old, to find them. And if you have dessigned your
userdata relying on __gc() it is going to be hard. There are many ways
to do it, but it requires knowledge of the usage patterns of the
object.

Francisco Olarte.