Mike, thanks for explaining why I'm seeing the results I'm seeing. Yichun, I'll take a look at lj-gc-objs. It looks like it could be helpful. Thanks! greg On Sat, Mar 15, 2014 at 2:54 PM, Yichun Zhang (agentzh) <agentzh@xxxxxxxxx>wrote: > Hello! > > On Fri, Mar 14, 2014 at 6:39 PM, Benn Bollay wrote: > > Once you identify the piece of memory that's lingering, are there any > tools > > available for determining why the GC decides not to collect it? > Something > > that could indicate where the reference is being held, for example, by > > returning something like "_G_['foo']['bar']['bah']"? > > My lj-gc-objs tool essentially walks through all the GC objects in the > same way as the "sweep" phase of the GC cycle. > > To get the reference route from the GC roots to a particular GC object > you're interested in, you can just create another stap (or gdb) tool > that walks through all the live GC objects from the GC roots in the > same way as the "mark" phase of the GC cycle ;) > > LuaJIT GC's data structures already contain all the information we need > anyway. > > Best regards, > -agentzh > >