The memory used by lua codes is managed by the GC, not calling malloc/free directly.
The luajit GC uses mark-and-sweep algorithm. In simple words, it will links all gc objects in a
global list. When the memory is in pressure, it would trigger recycle procedures. Note that
because of single-threading design, the GC is interspersed in the flow of lua codes (either compiled
or interpretered), e.g. after string allocation. GC would try to check if the gc
object is still in used, e.g. as an upvalue, reside in a stack. The GC would sweep all dangling gc objects at the end, and the corresponding memory would be freed and returned to C allocator.
In luajit, lj_alloc_malloc and lj_alloc_realloc would allocate gc objects, and lj_alloc_free would
free them. So naturally, we could trace the invocations of these functions to check memory leak.
Note that triggering gc is a bit uncertain and the gc steps would be splited in different time slices. So it would not free unused memory immediately. Moreover, the lua codes may use caches. So it's necessary to check the codes to distinguish the real memory leak.
Please check my blog site: