marcoonroad
commented
7 years ago NOTE: If possible, it's better to avoid GC finalizer handlers. They could introduce some performance issues due the iterations running, and many iterations for every object being collected will be a huge slowdown on many soft-real time systems (for example, games and scientific/graphical programs). That said, I must look for another way to implement an efficient algorithm, but the whole idea of Lua v5.1 compatibility still matters cause many softwares (e.g, Love2D, Torch, SciLua) in the wild are using LuaJIT.
Despite the gc metaevent existing only on userdata, it is really possible to implement the support of the cloning families algorithm within this library on the Lua 5.1 version as well. We just need to provide another layer of abstraction/indirection, that is, we must decouple the finalizer meta-method (in the case, gc) from the current implementation on metatable.lua. Perhaps, another file/module called finalizer.lua could help us a lot. In this file, we could also detect the current Lua version, if it is 5.1 we just implement the finalizer with userdata/newproxy, otherwise, for the cases 5.2 and 5.3 we'll rather use a sole table. Such reference holding a finalizer must be unique and exclusively hold/pointed by the public object counterpart, whenever that public object is collected, that private reference will be collected as well and also will run the expected finalizer for our cloning families algorithm.