Deconstructing the LuaJIT Pseudo Memory Leak
blog.openresty.com
Deconstructing the LuaJIT Pseudo Memory Leak
1–6 of 6 posts
Re: Deconstructing the LuaJIT Pseudo Memory Leak
#2This 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.
Re: Deconstructing the LuaJIT Pseudo Memory Leak
#3I 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.
Re: Deconstructing the LuaJIT Pseudo Memory Leak
#4This 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.
[deleted]
Re: Deconstructing the LuaJIT Pseudo Memory Leak
#5This 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.
> 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.
Re: Deconstructing the LuaJIT Pseudo Memory Leak
#6This 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.
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...