Deconstructing the LuaJIT Pseudo Memory Leak

Deconstructing the LuaJIT Pseudo Memory Leak(blog.openresty.com)

15 points by dgares 174 days ago | 4 comments

rurban 170 days ago |

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.

writebetterc 170 days 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.

fsfod 170 days 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...

bakugo 170 days 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.