To which extent LuaJIT is specific to Lua
- From: Leo Romanoff <romixlev@xxxxxxxxx>
- To: "luajit@xxxxxxxxxxxxx" <luajit@xxxxxxxxxxxxx>
- Date: Fri, 29 Nov 2013 08:16:40 -0800 (PST)
Hi Mike,
Robin Heggelund Hansen asked today a lot of interesting questions about tracing
compilers.
I'd like to ask a few more questions, but specifically about LuaJIT.
Basically, LuaJIT is one of the best or may be the best tracing JIT available.
But it is currently used only/mostly for Lua, even though it could potentially
bring a lot of benefits to many other languages and their implementations.
Therefore, the overall theme of my question is:
Is it possible to use (a correspondingly extended) LuaJIT as a generic tracing
JIT for other languages with different semantics and execution models? Or is
LuaJIT so tightly coupled to Lua, its semantics and execution model that it is
almost impossible to reuse it for something significantly different from Lua
without rewriting it almost completely?
I understand that LuaJIT was initially created specifically for Lua. But I'm
wondering to which extent LuaJITs inner organization, design and implementation
are tied to the semantics of Lua. I can imagine that some parts of LuaJIT (e.g.
machine code generation, register allocation, some generic optimizations) are
not that much dependent on Lua and its semantics, while some other parts (e.g.
some of optimizations) are rather tightly coupled to Lua, because they are only
possible if Lua semantics is assumed (e.g. table indexing starts with 1,
strings are interned, etc).
So, I'm wondering which parts of LuaJIT are generic and which ones are tightly
based on Lua semantics? The reason for this question: I'd like to understand
better if LuaJIT could be used as a tracing JIT backend for something very
different from Lua in its semantics. I understand that it is most likely not
possible out of the box and would require adaptations and extensions of LuaJIT.
But the question is - how much work would it be? Would one need to rewrite
almost all of LuaJIT or may be there are only few places in the code that are
very much dependent on the language semantics and therefore need to be
adjusted/changed to meet the semantics of a different language? And I'm really
in using LuaJIT directly, without mapping the original source language to Lua
first, even though it could be possible in some cases.
Some examples of the languages and features I have in mind are:
- some sort of statically typed language like C/Pascal/etc
- something like JVM-based languages, e.g. Java, Scala? You said yourself that
LuaJIT beats JVM in many cases.
- some scripting languages, which have a different internal object/execution
model, e.g. Python or Ruby
- features like: custom object layouts in memory (e.g. C-like structs vs Lua's
tables), custom garbage collectors, support for custom ABIs.
Thanks,
Leo
Other related posts:
