Deconstructing the LuaJIT Pseudo Memory Leak (opens in new tab)

(blog.openresty.com)

15 pointsdgares2mo ago4 comments

4 comments

I only see Mike Pall's commits in https://github.com/openresty/luajit2/commits/v2.1-agentzh/ (agentzh's branch). So it looks Cloudflare has to pay for this mtrim patch.

writebetterc2mo ago

This has to be AI slop text... It doesn't actually say what it does. If you've got a non-compacting GC that's fragmenting memory. If you need to release memory, then you better make sure that the blocks the GC is using are empty, and munmap them.

fsfod2mo ago

I think they just swapped out LuaJIT's modified built-it dlmalloc[1] with some standard allocator. Then just set some turning values of the allocator to make to more eager to return pages with no allocations left to the OS. LuaJIT has always had pluggable allocator system you can set at state construction time[2], it did have a restriction you could only use the built-it allocator for 64 bit builds if you don't use the GC64 build option, but thats been default enabled for a while now.

[1]: https://github.com/LuaJIT/LuaJIT/blob/v2.1/src/lj_alloc.c

[2]: https://github.com/LuaJIT/LuaJIT/blob/707c12bf00dafdfd3899b1...

bakugo2mo ago

> This isn’t simply a code quality issue; rather, it stems from a “communication gap” between the runtime memory allocation mechanism and the operating system

> It is not merely a patch, but an enhanced runtime environment

> This is not merely a code quality issue, but a profound architectural challenge

Didn't even have to read past the opening.

j / k navigate · click thread line to collapse