Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Walk with LuaJIT

polarsignals.com

Post reply on HN
Print view View original

21–28 of 28 posts

Re: A Walk with LuaJIT

#21

Post by binary132 »

mordnis wrote: post #20
versteegen wrote: post #19

Earlier quoted context omitted.

Kudos! Was it difficult to get it accepted? I've seen ports rejected.

To be honest, I forgot because it was quite some time ago. But I don't think we had any difficulties in that regard. I do remember being quite worried that it will not be good enough. In the time I started working on it, Mike sent a brutal email to a person trying to do PPC64 port ( https://www.freelists.org/post/luajit/PPC64le-port-status,1 ).

LOL, vicious! I don’t feel sorry for them though — I learned a lot by getting a few harsh corrections when I was a young lad trying to run with bigger dogs.

Re: A Walk with LuaJIT

#22

Post by BugsJustFindMe »

tecleandor wrote: post #15
krapp wrote: post #12

Earlier quoted context omitted.

The workaround for LuaJIT moving to Github was to... clone a fork of it? If they could do that, why can't they just pull from the LuaJIT repo?

LuaJIT didn't move to GitHub, they just have a mirror there. 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.

> it's all a rolling release without any name or number, so you cannot snapshot I'm certain version

A git commit SHA is a number that identifies a version of the code.

Re: A Walk with LuaJIT

#23

Post by aktau »

gnurizen wrote: post #8

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!

I'd love to use this to profile Neovim, where (nowadays) user scripts are often written in Lua 5.1. Neovim by default embeds LuaJIT (close to HEAD). Being able to see Lua functions and C functions in the stack would be amazing.

Is there a single-shot mode that I can use from the command-line? Something like:

    $ parca-perf record nvim ...
Or:

    a$ nvim ...
    b$ parca-perf top -p $(pidof nvim)

Re: A Walk with LuaJIT

#24

Post by brancz »

aktau wrote: post #23
gnurizen wrote: post #8

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!

I'd love to use this to profile Neovim, where (nowadays) user scripts are often written in Lua 5.1. Neovim by default embeds LuaJIT (close to HEAD). Being able to see Lua functions and C functions in the stack would be amazing. Is there a single-shot mode that I can use from the command-line? Something like: $ parca-perf record nvim ... Or: a$ nvim ... b$ parca-perf top -p $(pidof nvim)

There isn’t, because the indented way to use Parca is to profile production and always-on.

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].

[1] https://www.parca.dev/docs/quickstart/

Re: A Walk with LuaJIT

#25

Post by gnurizen »

aktau wrote: post #23
gnurizen wrote: post #8

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!

I'd love to use this to profile Neovim, where (nowadays) user scripts are often written in Lua 5.1. Neovim by default embeds LuaJIT (close to HEAD). Being able to see Lua functions and C functions in the stack would be amazing. Is there a single-shot mode that I can use from the command-line? Something like: $ parca-perf record nvim ... Or: a$ nvim ... b$ parca-perf top -p $(pidof nvim)

It should work to profile neovim, does it use the luajit shared library or is it statically linked? You could run parca-agent and set up a filter to discard all non-neovim samples and leave a parca instance running locally and just restart it periodically.

Re: A Walk with LuaJIT

#26

Post by tecleandor »

BugsJustFindMe wrote: post #22
tecleandor wrote: post #15

Earlier quoted context omitted.

LuaJIT didn't move to GitHub, they just have a mirror there. 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.

> it's all a rolling release without any name or number, so you cannot snapshot I'm certain version A git commit SHA is a number that identifies a version of the code.

Yep, but it doesn't serve as model of reference of date, order, patch or anything, and it's meaningless without the git database. It's OK as an immutable tag, but doesn't give you any additional information.

Even without SemVer, using a simple date versioning system (let's say 2024.10.2-patch4) gives you a lot of context.

Re: A Walk with LuaJIT

#27

Post by mraleph »

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)

Re: A Walk with LuaJIT

#28

Post by aktau »

gnurizen wrote: post #25
aktau wrote: post #23

Earlier quoted context omitted.

I'd love to use this to profile Neovim, where (nowadays) user scripts are often written in Lua 5.1. Neovim by default embeds LuaJIT (close to HEAD). Being able to see Lua functions and C functions in the stack would be amazing. Is there a single-shot mode that I can use from the command-line? Something like: $ parca-perf record nvim ... Or: a$ nvim ... b$ parca-perf top -p $(pidof nvim)

It should work to profile neovim, does it use the luajit shared library or is it statically linked? You could run parca-agent and set up a filter to discard all non-neovim samples and leave a parca instance running locally and just restart it periodically.

At least if one self-compiles Neovim (which I do), it's statically linked.
Post reply on HN