Re: problem with the garbage collecting.

[Javier Guerra Giraldez <javier@...>]

On Sat, Sep 26, 2015 at 9:57 AM, Thierry <thi@thierry.1s.fr> wrote:
> NOTE: it is mandatory to force the GC after the execution of some
> Lua code because the allocated resources can be heavy and must be freed
> ASAP.


short answer: if you need to release resources deterministically (of
even just eagerly), don't rely on GC. it's better to do a :close()
method that you call as soon as you don't need your object.


long answer:

it is in the nature of GC that there's no guarantees of _when_ it will
collect objects.  on some languages, it's a stated goal to be as eager
as possible, sometimes even resorting to reference counting despite
all its known drawbacks; this is not the case in Lua, where GC tries
to do as little work as possible, and objects can (and do) remain in
memory for a long time after not being referenced anywhere.

the Lua GC is driven by "memory pressure", but it doesn't have any
access to C pointers, or other resources.  the userdata objects are
treated as black boxes, and they are accounted only for their declared
size.  In many cases, a userdata object is only a pointer to the real
data, so it exerts extremely low "pressure".

it's possible to have many of these very small objects, the rest of
the system is choking full of malloc()ated memory, lots of files open,
and the Lua VM is totally "too bad, not my problem, I only have these
thousands of tiny objects".


oh, and about handling errors: yes, Lua doesn't have a 'finally'
clause, like it doesn't have 'try...catch', but it's not hard to
implement either with pcall().  it's not just for "dangerous code",
it's also quite good to get the chance to release resources.


cheers,

-- 
Javier