Hacker News Reader

Comment by diego_moita | Hacker News Reader

There are so many forks of LuaJIT going on (raptorjit, luavela, moonjit, openresty's luajit 2, shine, ... The bad thing is that each one tries to fix a different issue: compatibility with new versions of the language, eliminate the 2 Gb limit, make more maintainable code, add extensions for web handling,...

And then, some of them introduce new problems such as limiting the number of available platforms.

View on HN

FWIW, if RaptorJIT had not ripped out arm64, I would have ended up recommending replacing Luajit with RaptorJIT in Fedora and not bothered with forking moonjit.

Indeed, I've been looking at writing a new backend (ambitious and foolish, many have tried, I know), so I was looking for the hottest fork, but RaptorJIT specifically guts most of the backends, and the other forks were not really doing anything.

RaptorJIT has a mostly finished port of the bytecode interpreter to C. That should make new arches /much/ easier to support because you don't have to hand-code a VM in asm, only write a JIT assembler backend. Check it out at https://github.com/raptorjit/raptorjit/pull/254

Current status is that it passed the LuaJIT test suite but that's not 100% coverage and it doesn't call into the JIT yet.

What sort of performance have you been getting?

Why not use the openresty fork which looks to be properly maintained?

That was my second fallback until a couple of months ago and in fact I did some work for openresty too for luajit. Openresty luajit2 however has a bunch of extensions that are incompatible with Lua and luajit, making it unsuitable as the stock luajit replacement. It would be possible to make those extensions conditional on build flags but the blocker there was the fact that the maintainers did not seem keen on doing releases and more importantly, moving too far away from luajit. Overall it was just simpler to start doing releases myself to fulfill a need (a more central place to maintain fixes for distributions) and then work towards a convergence.

Out of interest, which one removes the 2 GB limit? That was a reason I used the standard lua a while ago.

There's a patch for LuaJIT that increases the limit. It comes pre-applied with the LuaJIT that installs with openresty. https://github.com/openresty/lua-nginx-module/issues/1019

There is no 2GB limit if LuaJIT built in GC64 mode. It was an opt-in build time option until 13 days ago now its on default for 64 bit builds https://github.com/LuaJIT/LuaJIT/commit/bd00094c3b50e193fb32...

Reply on news.ycombinator.com