A Walk with LuaJIT(polarsignals.com) |
A Walk with LuaJIT(polarsignals.com) |
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!
Is there a single-shot mode that I can use from the command-line? Something like:
$ parca-perf record nvim ...
a$ nvim ...
b$ parca-perf top -p $(pidof nvim)However, we wouldn’t be against adding a mode like this!
FWIW both the server and the agent are single statically linked binaries so while it’s a bit more set up it’s not terribly difficult either[1].
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!
https://github.com/LuaJIT/LuaJIT/issues/1092
Q: does anyone know timeline on the release?
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
If they could do that, why can't they just pull from the LuaJIT repo?
The thing is they stopped numbering and publishing releases, it's all a rolling release without any name or number, so you cannot snapshot I'm certain version.
But OpenResty fork does create tag versions with date, so they can build or test against certain concrete snapshot frozen in time.
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)
A git commit SHA is a number that identifies a version of the code.
Even without SemVer, using a simple date versioning system (let's say 2024.10.2-patch4) gives you a lot of context.
So, I’m sure it’ll get worked on when he can, and it’ll be great when it’s done, but it doesn’t look like there’s active development on it and it doesn’t look like it will happen any time soon. I hope in wrong, of course, but it just doesn’t seem likely.
For example there is a new higher-performance GC (https://github.com/LuaJIT/LuaJIT/issues/38#issuecomment-1696...) since a year ago (in fact, at least 3 people over the years have taken a stab at writing a new GC!)
And a full port to (certain flavours of) RISC-V was finished a couple months ago and awaiting merge (https://github.com/LuaJIT/LuaJIT/pull/1267), and might be merged separately into the OpenResty fork (https://github.com/openresty/luajit2/pull/236).
> Is the sponsor prepared to sponsor the initial review and integration into the LuaJIT default code base by me?
> Is the sponsor prepared to sponsor the inevitable initial bug fixes and the extra effort for continued maintenance that a new architecture entails?
Also, I should have been clearer about the new GC I linked to: I have not seen Mike say anything about it, and I wouldn't be surprised in the least if he rejects it and (wishes to) write his own, because he's had his own plans for many years. It seems impossible to get anything past him without modification. (I think it's a pity to see someone send a PR with a highly informative commit message and he replaces the body with "Thanks to X. #987")
[1] https://github.com/LuaJIT/LuaJIT/issues/628#issuecomment-716...
Though, it is possible that he changed his mind after having to review thousands of lines of assembly written by 25 year olds. :)