I wrote the code and the blog, happy to answer any questions/comments. Very eager to have folks try it out and give feedback! Like is my meme game strong or very strong? J/K

There's some missing bits around FFI and callbacks (i.e. C calling function pointer that is a luajit generated stub back into the interpreter) and curious if anyone actually uses these things in OpenResty workloads. Deploy and enjoy!

Thanks for submitting! We know HN has a sweet spot for LuaJIT, so we figured it would eventually end up here.

Quick summary: this post dives into the gory details of how we implemented an eBPF based profiler for LuaJIT.

Let us know if you have any questions on this, we’ll keep an eye out on comments!

I’m tremendous excited about LuaJIT 3.0 development.

https://github.com/LuaJIT/LuaJIT/issues/1092

Q: does anyone know timeline on the release?

LuaJIT.org stopped publishing release tarballs [1] which caused leafo's GH actions builds [2] to suddenly stop working. The workaround was to start testing against OpenResty's distribution of LuaJIT [3] which is incompatible with LuaJIT.org's version.

There is no faster way to make a fork the de facto standard version than to break everyone's CI builds.

[1] https://luajit.org/download.html

[2] https://github.com/leafo/gh-actions-lua/issues/49

[3] https://github.com/openresty/luajit2

At some point in my life (when I briefly worked on LuaJIT for DeepMind) I have written a stack walker which can stitch together native and Lua frames: for each native stack frame it checks if that is actually an interpreter frame or a trace frame - if that's the case it finds corresponding `lua_State` and unwinds corresponding Lua stack, then continues with native stack again.

This way you get a stack trace which contains all Lua and native frames. You can use it when profiling and you can use it to print hybrid stack traces when your binary crashes.

I was considering open-sourcing it, but it requires a bunch of patches in LJ internals so I gave up on that idea.

(There is also some amount of over-engineering involved, e.g. to compute unwinding information for interpreter code I run an abstract interpretation on its implementation and annotate interpreter code range with information on whether it is safe or unsafe to try unwinding at a specific pc inside the interpreter. I could have just done this by hand - but did not want to maintain it between LJ versions)

Lua and Nginx are fantastic. Did you know it's possible to add behavior/code lua for openrest dynamically? https://github.com/leandromoreira/lua-resty-dynacode?tab=rea...