Hacker News Reader

Comment by hbbio | Hacker News Reader

It's an impressive project that shows the extraordinary work of a single developer, Mike Pall. LuaJIT is not only an incredibly beautiful JIT, the current project also demonstrates it can run generated code efficiently, which is probably the hardest thing to do for a language.

When implementing Opa in OCaml, we run into tons of problem since the OCaml runtime was unable to run generated code efficiently. One of its author, Pierre Weis told us at the time: "it's normal, OCaml is not meant to run generated code at all".

As a side note regarding Luje source code: Fossil must be great and all that but having the code on a publicly available Git repository would probably bolster contributions.

View on HN

Luajit is of course awesome, but let's not get too carried away. It doesn't sound like this JVM has been used for running anything beyond extremely simple benchmarks. Of course you're not going to run into difficulties with the translation of a 15 line method.

I saw a talk Mike gave on Luajit last week, and one thing he credited Luajit's success on was that it was working on a rather high abstraction layer. Stuff like the loop optimizations and alias analysis work because the optimizer can essentially understand the code at a fairly high level, and is somewhat specific to Lua. When dealing with java translated to jvm bytecode naively translated to lua source you lose much of that context. (And at the time he didn't seem too convinced about using luajit as the backend for other languages.)

But even if you ignore the loss of context, I'm sure that various luajit limits would get hit with real life Java code. E.g. I'd guess there's a fundamental 65k limit for the number of constants and bytecode instructions in a single function.

JVM bytecode is quite nasty from this point of view; one of Mike's comments in the mailing list was to try Dalvik instead. It loses a lot of loop structure.

http://www.freelists.org/post/luajit/ANN-luje-01

Is this talk available on the web in any form?

Sorry, it wasn't recorded.

.class files are a fairly simple mechanical translation from java into bytecodes making them easy to decompile. Many optimizations that a compiler would do for static code are not done as the JIT can decide at runtime.

The Java->OpenCL framework https://code.google.com/p/aparapi/ decompiles kernels written in Java class files back into algebra and reprojects them into OpenCL.

The peformance of a LuaJIT based JVM could actually be quite good depending on how much work is done in the decompilation stage.

Did anybody take notes from the Mike Pall's LuaJIT talk? I've been asking around on Twitter, but no luck so far. (My contact info is in my profile.)

Reply on news.ycombinator.com