Moonjit – Fork of LuaJIT to Continue Development

Re:Moonjit – Fork of LuaJIT to Continue Development by diego_moita on Saturday December 21, 2019 @10:08AM (#21851489)

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.

[ Parent | on HN ]

Re:Moonjit – Fork of LuaJIT to Continue Development by siddhesh on Saturday December 21, 2019 @10:50AM (#21851708)

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.

[ Parent | on HN ]

Re:Moonjit – Fork of LuaJIT to Continue Development by microcolonel on Saturday December 21, 2019 @11:12AM (#21851830)

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.

[ Parent | on HN ]

Re:Moonjit – Fork of LuaJIT to Continue Development by lukego on Saturday December 21, 2019 @11:32AM (#21851946)

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.

[ Parent | on HN ]

Re:Moonjit – Fork of LuaJIT to Continue Development by microcolonel on Saturday December 21, 2019 @11:38AM (#21851982)

What sort of performance have you been getting?

[ Parent | on HN ]

Re:Moonjit – Fork of LuaJIT to Continue Development by armitron on Sunday December 22, 2019 @09:02AM (#21857142)

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

[ Parent | on HN ]

Re:Moonjit – Fork of LuaJIT to Continue Development by siddhesh on Sunday December 22, 2019 @11:49AM (#21858176)

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.

[ Parent | on HN ]

Re:Moonjit – Fork of LuaJIT to Continue Development by anfractuosity on Saturday December 21, 2019 @01:34PM (#21852599)

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

[ Parent | on HN ]

Re:Moonjit – Fork of LuaJIT to Continue Development by fsfod on Saturday December 21, 2019 @04:41PM (#21853496)

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

[ Parent | on HN ]

Re:Moonjit – Fork of LuaJIT to Continue Development by leafo on Saturday December 21, 2019 @01:58PM (#21852723)

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

[ Parent | on HN ]