A whirlwind tour through the LuaJIT VM, by its creator
Talk by Mike Pall
Notes by Felix Rabe — feel free to integrate with your own notes if you were at the event!
2013-Oct-03 at the Zurich FLOSS and IT geeks meetup: http://www.meetup.com/zhgeeks/events/141272252/
2005
Business logic
Codebase in C
Lua 5.0 -> 5.1
incremental GC
low-latency requirements
delays of 100ms not acceptable / affordable
Got involved in Lua community (patches, ...)
At the time, Lua's performance was top-5
Tail calls = "kind of goto"
Syntax does not matter, what matters is semantics
2005...
Projects was abandoned
Stayed with Lua community
Lua bytecode
(Stupid) register(-based) allocator
IR
Dataflow
64-bit representation (very little for compilers / IA)
linear IR
PHI's at the end
IR => assembly goes backward (to allocate registers)
x86 FPU is fast, often waste not to use it
ARM often uses integers (weak FPU); overflow check
Branches get patched when new traces are introduced
Counters on looping instructions are used to determine hot code areas
Dynamic languages have a lot of guards
C preprocessor-based DSL
C compiler does not know what aliases what (pointers!)
Luajit knows what tables do (not) alias other tables
Allocation sinking
Q: Tail recursion?
Not many Lua users write recursive code
Not very optimized
Don't get lost in the details (=> Spidermonkey / Tracemonkey), stick to what's important:
Loop optimization
Alias ...
Sparse snapshotting, only where necessary (Tracemonkey: snapshot after every instruction)
Tracemonkey people had no experience writing compilers
Luajit 1 => Luajit 2
Do not write a trace compiler for your thesis!
Cloudflare: Web application firewall
Huge amount of rules (blacklisting...)
Ahead-of-time optimization cannot adapt to changes
Luajit does pay for the time invested, but not a full-time project
Not too interested in money: fun => keep going
Advantage: Luajit built on existing Lua ecosystem => large body of code already available
Not optimizing corner cases